-
-
Notifications
You must be signed in to change notification settings - Fork 0
fix: clean up dangling event listeners after auditing event listeners #81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| reject(error); | ||
| }) | ||
| .finally(() => { | ||
| this.dappClient.off('message', dappClientMessageHandler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might only want this in the catch. If it's in the finally, we might unsubscribe before the event listener has processed a wallet_createSession response?.. @adonesky1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5217c82 moved into catch clause
| if (initialConnectionMessageHandler) { | ||
| this.dappClient.off( | ||
| 'message', | ||
| initialConnectionMessageHandler, | ||
| ); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think when @adonesky1 and I looked at this, we may have discovered that this listener was the only one also listening for wallet_sessionChanged, caching the value and/or notifying callbacks for it.
We need to verify subsequent wallet_sessionChanged events still come through
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think handleMessage is written correctly to be a stand in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can remove this unsubscription from here then if wallet_sessionChanged depends on it, but we run into an issue where this handler never removed, meaning if connect() is called multiple times, multiple handlers accumulate (each call adds a new one).
also seems like handleMessage is processing the same wallet_sessionChanged notifications, but that method is such a confusion pile I'm not even sure what to say regarding this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5217c82 moved removal of listener if payload has error, but might be open to issue I stated above
| if (initialConnectionMessageHandler) { | ||
| this.dappClient.off('message', initialConnectionMessageHandler); | ||
| initialConnectionMessageHandler = undefined; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think we want to do this in the finally since the wallet_sessionChanged may not have arrived at this point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5217c82 moved into catch clause
Explanation
This PR proposes a clean up to a couple dangling event listeners we had across
connect-multichain,connect-evmand mwp transport.1. ✅ connect-evm/src/connect.ts - Fixed duplicate
onNotificationlistener2. ✅ MultichainCore deeplinkConnect - Fixed potential listener leak
3. ✅ MWPTransport - Fixed duplicate
dappClient.on('message')listenerReferences
Checklist