Conversation
On keystore deregister the accounts linked to the keystore were closed and sent statusChanged events to the frontend + a final `accounts` event to notify the change in the accounts number. The lag between the status and the accounts events caused the execution of calls towards endpoint of already closed accounts, which generated unexpected errors. This send an accounts event immediately after each account close, fixing the lag.
`emitAccountsStatusChanged` is a misleading name, as it doesn't fire an event connected to the account status, but about the number of available accounts. As it is catched in the frontend by `syncAccountsList` subscription, now it is called `emitAccountsListChanged`.
benma
left a comment
benma
left a comment
There was a problem hiding this comment.
n keystore deregister the accounts linked to the keystore were closed
and sent statusChanged events to the frontend + a finalaccountsevent
to notify the change in the accounts number. The lag between the status
and the accounts events caused the execution of calls towards endpoint
of already closed accounts, which generated unexpected errors.
I have a hard time understanding this. Which statusChanged event exactly?
| backend.onAccountUninit(account) | ||
| } | ||
| account.Close() | ||
| backend.emitAccountsListChanged() |
There was a problem hiding this comment.
at this stage backend.accounts has not changed at all though, so why fire an event here?
There was a problem hiding this comment.
Good point, I guess I'd have to remove the single accounts from the slice after each iteration and then firing the event. Agree?
This https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/backend/coins/btc/account.go#L457 |
2 participants
Fixes an event transmission lag that caused an unexpected error (discovered in #2307) and renames a misleading backend method. See commit messages for details.