fix(wallet): close the relay socket on the way out, so the return is one dial

[ehsan6sha]

First diagnostic log from the reporter's phone (build 7187fba, via the debug banner from #38). The return from the connect approval:

[tab] visible after 28875ms hidden
[relay] socket is down (connecting=true) — opening the transport
[relay] transportOpen did not get the socket up within the bound — restarting the transport   (+2503ms)
[relay] transport restart finished in 8272ms, connected=true                                  (+8273ms)
[wallet] connected=true                                                                       (+8651ms)

What the seconds were

Not a zombie socket — the theory #36 was built on. A socket that was down, with a connect attempt pending. While the tab was hidden Android took the network, the socket closed, and the library did what it does on a close: scheduled a reconnect, dialled, failed, slept its backoff, dialled, failed, slept longer. connect() retries five times with a sleep of attempt seconds between. The tab came back in the middle of one of those sleeps with connectPromise pending, and everything awaits that promise — the library's own transportOpen() and every lever in relayWake. Nothing can cancel a setTimeout inside the library. So the return paid the rest of the sleep, then one dial, plus 2.5 s of our own bound waiting on a promise that could not resolve inside it. Nine seconds, none of them a dial that reached the relay.

The third return in the same log landed at a luckier point in the loop and took 1.5 s. That is the floor: one dial on that network.

The fix

transportClose() the moment the tab goes hidden. It sets transportExplicitlyClosed — the one flag every auto-reconnect path checks first — so nothing dials a network that is not there, no backoff accrues, and no promise is pending when the tab returns. connect() clears the flag on the way back in, so transportOpen() on visible is a single clean dial. The wallet's approval or signature, published while we were away, is queued by the relay against its topic and pushed on re-subscribe (hasAnyTopics counts cached subscriptions, so the reopen proceeds). The close happens while the user is in the wallet, where no one is waiting on it.

Expected: return delay drops from ~8.6 s to ~1.5 s on the reporter's network. The log lines will say.

Also from the log

[relay] fresh socket up in 1ms on the second return. #38's fast path checked connected — which the socket being replaced still reports, that being the whole problem — so it congratulated the dead socket. It now requires a new provider object as well as OPEN before declaring success.

Also: the guards route test gets a budget a busy runner can meet

set up → / lands on /blox still missed its 15 s waitFor about one full-suite run in three after #37 — on CI and locally, with nothing else competing. The Blox screen's chunk is the largest in the app and Vitest transforms it in a worker sharing the machine with every other file; alone it takes ~2.4 s. The test asserts which route matched, never how fast, so ROUTE_TIMEOUT goes to 30 s. That is the last known source of red-with-everything-passing on main.

Testing

npm test --workspaces clean. New: parkRelay closes an open or mid-dial socket and leaves a down one alone; the hook parks on hidden and the return is a single transportOpen; without transportClose to park with, a socket still claiming OPEN on return is replaced; the fast-path fallback test now models the dead socket still reporting OPEN and asserts the restart actually replaced the provider.

🤖 Generated with Claude Code

https://claude.ai/code/session_013BpqXrkEPA9odTyRdK5Mnx