Events are not emitted while the wallet client is closed
Describe the bug (current behavior) Switching accounts on the wallet side while the DApp is closed, does not emit an event on the next page load.
To Reproduce
- Go to the latest example DApp
- Click
Request Permissions, copy the QR code, open a new tap on ghostnet.kukai.app → Settings (cog icon) → SCAN QR CODE (this uses the wallet-connect transport) → paste the QR code payload - Close the tab where the DApp was open
- On the tab where Kukai is opened, go to Settings (cog icon) → Sessions (under Wallet Connect) → click the pencil icon to switch to a different account
- Close the kukai tab, your are now left with no active tabs.
- Open a new tab and go to the example DApp, like step 1
- There will be no subsequent
SET_ACTIVE_ACCOUNTevent, the address will not be updated since the wallet client is closed.
https://github.com/airgap-it/beacon-sdk/assets/41209538/3fb29b08-c54c-458e-8e29-291367ea03e2
Expected (correct) behavior Sessions should not depend on an active wallet client. This indicates that the event system relies on the wallet to emit events regarding sessions.
Hi @AlexandrosGounis,
Unfortunately after addressing this issue, the very first time we load the page, signClient always returns the old session.
However, refreshing the page fixes the issue.
I am having a hard time uploading my recording because of size limit. If you want I can share it on Slack. But basically, follow the same steps you mentioned with the build below. Look for a log in the console which says 'init session getAll'. That log shows all the sessions signClient is currently holding.
https://8c25eafaac5f00544f5f9dcc4e93141b6d63187e--beacon-sdk.netlify.app/dapp PR: #767
@IsaccoSordo, yes, as you mentioned, refreshing the page fixes the issue. However, this is not a signClient issue. Our wallet-connect example works on every page load, without having to reload. There might be some other internal beacon issue that prevents the signClient from getting the last active session.
This issue is resolved in v4.3.0.
Because Beacon requires the public key for its internal state, once we receive a session_update from the wallet, we request the public key through tezos_getAccounts. In the scenario you described, this operation is blocking.
However, the wallet can send the public key immediately to prevent this behavior.