Skip to content

Conversation

@ffmcgee725
Copy link
Member

Explanation

This PR proposes a clean up to a couple dangling event listeners we had across connect-multichain, connect-evm and mwp transport.

1. ✅ connect-evm/src/connect.ts - Fixed duplicate onNotification listener

2. ✅ MultichainCore deeplinkConnect - Fixed potential listener leak

3. ✅ MWPTransport - Fixed duplicate dappClient.on('message') listener

References

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

@ffmcgee725 ffmcgee725 requested a review from a team as a code owner December 11, 2025 10:48
reject(error);
})
.finally(() => {
this.dappClient.off('message', dappClientMessageHandler);
Copy link
Contributor

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

Copy link
Member Author

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

Comment on lines 377 to 382
if (initialConnectionMessageHandler) {
this.dappClient.off(
'message',
initialConnectionMessageHandler,
);
}
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Member Author

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

Comment on lines 434 to 437
if (initialConnectionMessageHandler) {
this.dappClient.off('message', initialConnectionMessageHandler);
initialConnectionMessageHandler = undefined;
}
Copy link
Contributor

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

Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants