Skip to content

Conversation

chakra-guy
Copy link
Contributor

@chakra-guy chakra-guy commented Sep 16, 2025

Description

This PR is part of the larger initiative to integrate the new Mobile Wallet Protocol (MWP). It completes core logic by integrating multichain RPC message handling between the dApp and the wallet.

Project Roadmap:

  • Scaffolding
  • Connection Handling
  • UI Integration
  • Connection Resumption & App State Handling
  • RPC Message Handling (Bridge Integration) (This PR)

This PR:

  • Enables Multi-chain in BackgroundBridge: Activates the MultichainSubscriptionManager for MMSDK V2 connections, enabling multi-chain capabilities for the SDK.
  • Introduces RPC Bridge Adapter: Adds a new client that wraps the BackgroundBridge to:
    • Provide a simplified and clean interface for consumers.
    • Implement lazy initialization, creating the bridge client only when it's first needed to optimize performance.
    • Manage a message queue to reliably handle requests that may arrive before the wallet/background-bridge is fully initialized and ready.
  • Adds Throttling to handleConnectDeeplink: Implements throttling as a defensive measure to prevent issues caused by rapid, repeated calls to the deep link handler.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

No manual testing is needed. This PR introduces headless core logic that is not yet fully connected to the UI. Comprehensive manual testing will be performed in a subsequent PR once the end-to-end flow is complete.

Screenshots/Recordings

Before

N/A (Logic change only)

After

N/A (Logic change only)

Pre-merge author checklist

Pre-merge reviewer checklist

  • I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
  • I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

@metamaskbot metamaskbot added the team-sdk SDK team label Sep 16, 2025
Copy link
Contributor

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

getProviderState: any;
}) =>
getRpcMethodMiddleware({
hostname: middlewareHostname,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be the origin value? previously connection.origin?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly I don't think we can do that. A bunch of old code relies on the middlewareHostname to have this very specific format for routing. It's kinda silly..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More context: a bunch of routing and UI code relies on this prefix

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... Well I've made this change to setupBridge and I don't think I saw any issues come out of it. Does this seem right or wrong?

@chakra-guy chakra-guy changed the title feat: hooking up the requests/responses with the bridge feat(SDKConnectV2): RPC Message Handling Sep 18, 2025
@chakra-guy chakra-guy marked this pull request as ready for review September 18, 2025 15:37
@chakra-guy chakra-guy requested a review from a team as a code owner September 18, 2025 15:37
cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

public async handleConnectDeeplink(url: string): Promise<void> {
public handleConnectDeeplink: (url: string) => Promise<void> | undefined;

private async _handleConnectDeeplink(url: string): Promise<void> {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Throttling and Loading State Issues

The handleConnectDeeplink method, now throttled, returns undefined instead of a Promise<void> during the throttle period, which breaks callers expecting to await its result. Also, showLoading is now called after parseConnectionRequest, potentially leading to unbalanced loading indicator states if parsing fails before showLoading is invoked.

Fix in Cursor Fix in Web

Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
28.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants