On a non-test device this setting was disabled, and had been for some time.
Observed that balances were not updating even after switching selected account, switching back, and providing a generous amount of time on a functioning network and active VPN. Upon further investigation noted that 10 day old (at that time, tx dated 6/12/2024) transaction was also not reflected in the account balance. Lock/unlock or killing the app and restarting did not help. Balance only updated after setting was re-enabled to batch balance requests.
Insufficient funds error prevented the confirm button from being active in a subsequent tx attempt, while the previously received transaction appeared in activity view and the account did in fact have sufficient funds according to block explorer.
Expected behavior
Given Batch account balance requests is disabled
When a transaction is received for the selected active account
Then the transaction shows in the activity view
And the account balance is updated (FAILS HERE)
1) Disable Batch account balance requests from Settings>Security & Privacy
2) Have multiple accounts present, at least one with assets you can send
3) Send tx from one address to another HD address in the wallet
4) Receive a tx and wait until its confirmed in activity view
5) Switch active account and network
6) Then switch back to the account/network under test and note that balance still has not changed
7) Enable batch account balance requests in Settings>Security & Privacy
8) Return to wallet view and note updated balance
Observed on:
HD account
Eth Mainnet
v7.24.3
Android v14
Severity
This setting is enabled by default, but can prevent transactions if the user disabled it and then expects the balance to be updated. Impeding a transaction that a user should otherwise be able to make could have some potential for funds loss. Or in the case of a balance decrement (initial tx a send rather than receive) there might be potential for funds loss if the user is allowed to confirm a subsequent tx that the balance does not support.
Describe the bug
On a non-test device this setting was disabled, and had been for some time.
Observed that balances were not updating even after switching selected account, switching back, and providing a generous amount of time on a functioning network and active VPN. Upon further investigation noted that 10 day old (at that time, tx dated 6/12/2024) transaction was also not reflected in the account balance. Lock/unlock or killing the app and restarting did not help. Balance only updated after setting was re-enabled to batch balance requests.
Insufficient funds error prevented the confirm button from being active in a subsequent tx attempt, while the previously received transaction appeared in activity view and the account did in fact have sufficient funds according to block explorer.
Expected behavior
Given Batch account balance requests is disabled When a transaction is received for the selected active account Then the transaction shows in the activity view And the account balance is updated (FAILS HERE)
Screenshots/Recordings
n/a was observed outside of testing/recording
Update:
https://github.com/MetaMask/metamask-mobile/assets/6626407/50f0e446-81b0-4a45-ad15-c050764d7732
Steps to reproduce
1) Disable Batch account balance requests from Settings>Security & Privacy 2) Have multiple accounts present, at least one with assets you can send 3) Send tx from one address to another HD address in the wallet 4) Receive a tx and wait until its confirmed in activity view 5) Switch active account and network 6) Then switch back to the account/network under test and note that balance still has not changed 7) Enable batch account balance requests in Settings>Security & Privacy 8) Return to wallet view and note updated balance
Error messages or log output
No response
Version
7.24.3
Build type
None
Device
Pixel 7a
Operating system
Android
Additional context
Discussion here: https://consensys.slack.com/archives/CBW7S9FSN/p1719439968931969
Observed on: HD account Eth Mainnet v7.24.3 Android v14
Severity
This setting is enabled by default, but can prevent transactions if the user disabled it and then expects the balance to be updated. Impeding a transaction that a user should otherwise be able to make could have some potential for funds loss. Or in the case of a balance decrement (initial tx a send rather than receive) there might be potential for funds loss if the user is allowed to confirm a subsequent tx that the balance does not support.