setup: in debug mode, put the request on the relay but do not open the wallet - #40
Merged
Conversation
…e wallet A diagnostic, not a feature. Two logs from the reporter's phone now say the same thing about the splash-screen hang. Every "retry" tested so far -- the request link from a real tap, the bare scheme -- went into a MetaMask that the FIRST hop had already wedged on its splash screen, so none of them tested whether the deep link itself is what wedges a healthy warm wallet. Meanwhile the one recovery the logs show working is a cold MetaMask picking the request up with no deep link at all: the 25 s window in the first log has no return to the page and no second hop in it, and the signature arrived 1.5 s after the tab came back. So the untested question is the only one left: does a healthy warm MetaMask show the prompt when it is resumed WITHOUT a deep link? With debug mode on, the sign tap now publishes the request and stops there -- the request is on the relay, the "Open wallet to approve" button is on screen, and a line under it says so -- and the user can switch to the wallet from recent apps and report what it shows. The button still fires the deep link afterwards, so the same run also tests the deep link against a wallet that has NOT already been wedged. Debug mode is an explicit opt-in used for exactly this kind of report; the default path is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013BpqXrkEPA9odTyRdK5Mnx
ehsan6sha
added a commit
that referenced
this pull request
Sep 5, 2026
…back to (#41) The third diagnostic log from the reporter's phone, run with #40's "do not open the wallet" debug mode: 16:21:54 [tab] visible -> connected=true (+609ms) MetaMask approved the pairing, sent the user back 16:21:56 [sign] request on the relay ... NOT opening the wallet 16:22:06 [tab] hidden user switched to MetaMask by hand -- no deep link 16:22:14 [tab] visible -- "it was hung on splash screen" MetaMask was already wedged BEFORE any deep link was sent to it. Twelve seconds after it approved the pairing and returned the user to the browser, it sat on its splash screen for a plain resume from recent apps. So the deep link was never the trigger, and every theory built on it -- URL shape, gesture, warm resume by intent -- is closed. Whatever puts the wallet in that state happens on the way it returns the user; the one thing here that makes it return the user at all is `providerMetadata.redirect` (chains.ts, added in #8 -- before that, MetaMask left the user in the wallet). So with debug mode on, `initAppKit` omits the redirect from the metadata it hands to the wallet. The wallet leaves the user where they are after approving, they switch back to the browser by hand, and when they switch to the wallet again for the signature the log says whether it is still healthy. Decided inside `initAppKit` because there are two call sites (LinkPassword's loader and WalletGate) and the first to run wins; AppKit reads the metadata once, so a change of debug mode needs a page reload. Default behaviour is unchanged. Claude-Session: https://claude.ai/code/session_013BpqXrkEPA9odTyRdK5Mnx Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A diagnostic, not a feature. Default behaviour is unchanged.
Why
Two logs from the reporter's phone (#38's banner) say the same thing about the splash-screen hang: every "retry" tested so far — the request link from a real tap, the bare scheme — went into a MetaMask that the first hop had already wedged on its splash screen. None of them tested whether the deep link itself is what wedges a healthy warm wallet.
Meanwhile the one recovery the logs show actually working is a cold MetaMask picking the request up with no deep link at all: the 25 s window in the first log contains no return to the page and no second hop, and the signature arrived 1.5 s after the tab came back.
So the one untested question is: does a healthy warm MetaMask show the prompt when resumed without a deep link?
What changes
With debug mode on, the sign tap publishes the request and stops there. The request is on the relay, Open wallet to approve is on screen, and a line under it says the wallet was deliberately not opened. The user switches to the wallet from recent apps and reports what it shows. The button still fires the deep link afterwards, so the same run also tests the deep link against a wallet that has not already been wedged.
The second log also confirms #39: the connect return went from 8.6 s to 0.84 s (
parked the socket … 59ms→transport open in 326ms→connected=true +844ms).Testing
npm test --workspacesclean. New: debug mode → request published, noassign, the note is shown, the button still hops, a late signature still lands.🤖 Generated with Claude Code
https://claude.ai/code/session_013BpqXrkEPA9odTyRdK5Mnx