Lisk-sdk: Balance change after new block is delayed by several seconds

[slaweet]

Steps to reproduce

1. Connect to socket.io of Lisk Core, e.g. wss://testnet.lisk.io/socket.io/?EIO=3&transport=websocket
2. Send a transaction from account A to account B
3. Wait for the 'blocks/change' socket event
4. Make RESTfull API Request to /api/accounts?address=<address_of_A_or_B>

Expected behavior

/api/accounts?address=<address_of_A_or_B> should contain balance updated by transaction done in step 2.

Actual behavior

/api/accounts?address=<address_of_A_or_B> contains balance unchanged

The balance will be changed only several seconds later.

Which causes issues in Lisk Hub like this https://github.com/LiskHQ/lisk-hub/issues/1188

/api/transactions has the same delay as /api/accounts

Another thing I noticed is that if the transaction in Step 2. is the first outgoing transaction of account A, then response in Step 4 already contains the publicKey, but still not the updated balance.

Which version(s) does this affect? (Environment, OS, etc...)

Lisk Core 1.0.0

[4miners]

The reason behind this behavior is the following:

• Cache for blocks and transactions is cleared in newBlock event https://github.com/LiskHQ/lisk/blob/70ffe0ab6254f95d1ede44050c990c87730aebd1/modules/cache.js#L234
• blocks/change event is emitted in broadcastBlock event https://github.com/LiskHQ/lisk/blob/70ffe0ab6254f95d1ede44050c990c87730aebd1/modules/transport.js#L425
• Both of them come from processBlock function, but broadcastBlock is emitted way before newBlock
  https://github.com/LiskHQ/lisk/blob/70ffe0ab6254f95d1ede44050c990c87730aebd1/modules/blocks/verify.js#L815 https://github.com/LiskHQ/lisk/blob/70ffe0ab6254f95d1ede44050c990c87730aebd1/modules/blocks/verify.js#L833

[slaweet]

@4miners thanks for the explanation.
So this it was changed between 0.9.X and 1.0.0 when blocks/change is emitted? Is there a reason for that?
Is there something else I can listen to for notification when the new block is fully processed?

[4miners]

@slaweet Not really, this is an inconsistent behavior and should be considered as a bug in Lisk Core and fixed.