Files
buzz/mobile/test/shared
Spencer Lewis 83d0bd3203 fix(mobile): stop QR pairing to organization relays from hanging (#9001)
## Problem

Pairing a phone to an organization relay by QR (for example Block's
`buzz.block.builderlab.xyz`) never finishes. After the codes match and
the phone confirms, it sits on the loading surface. About 2 minutes
later it returns to the welcome screen with "Lost connection to pairing
relay." The desktop stays on "Finishing pairing on your phone…". This
reproduces every time on Buzz 0.27.0, iOS 27.2, with desktop 0.7.7
(internal tracking: AIDA-2420).

There are two causes:

1. **Validation can never pass for organization relays.** After the
payload arrives, `_validateCredentials` opens a plain `RelaySocket`
without a `Nostr-Federated-Identity` assertion. Organization relays
refuse that upgrade with HTTP 401 until organization sign-in, which a
freshly pairing phone hasn't done.
2. **The failure hangs instead of erroring.** `RelaySocket.connect()`
catches the failed `ready` but keeps `_channel`. The validator's
`finally` then awaits `disconnect()` → `sink.close()` on a channel that
never opened, and that never completes. The phone waits until the
pairing relay's 120 s connection cap closes the socket, and
`_handleDisconnected` reports that as a lost connection.

Standalone repro with `web_socket_channel` 3.0.3 against the real relay:

```
ready failed: ... was not upgraded to websocket, HTTP status code: 401
sink.close() DID NOT COMPLETE within 30s (hang)
```

## Change

- `RelaySocket.connect()` drops a channel whose upgrade failed.
- `disconnect()` waits at most `RelaySocket.closeTimeout` (2 s). An
upgrade that is still pending (connect timeout 10 s) can outlive
pairing's 8 s validation deadline, and its close never completes either.
- `PairingNotifier` skips the pre-sign-in check for
`OrganizationEnvironment.protects` relays. Admission is left to the
saved community's session and the existing organization sign-in banner,
which matches how the hosted branch already defers admission. The
predicate is injectable (`organizationRelay`) for tests. Other relays
are still validated before saving.

Trade-off: an identity that the organization relay would reject is now
saved, and that rejection only surfaces after organization sign-in. The
hosted path has the same property.

## Related issue

No existing GitHub issue covers this failure; searched open issues and
PRs for pairing relay, lost connection and `_validateCredentials`.
Closest:

- #8043 / #8060 cover the same `_validateCredentials` path from the
other side: a failed connect currently returns normally. They're
complementary. With #8060 merged, organization relays would fail pairing
with an explicit 401 instead of hanging, and this PR keeps them out of
that pre-check. Whichever merges second needs a small rebase in
`_validateCredentials`.
- #3181 is a different failure in the same flow.

## Testing

- New `relay_socket_liveness_test` cases check that `disconnect()`
completes in three situations: after a refused (401) upgrade, after a
timed-out handshake, and while the upgrade is still pending.
- New `pairing_provider_test` case: a malformed key is rejected locally
before anything is saved, an organization relay is saved without the
relay check, and a non-organization relay is still validated and
rejected.
- Each new test fails with its fix removed. The failures were
"disconnect() hung on a channel that never opened", "disconnect() hung
on a pending upgrade", and `validated` being true.
- `just mobile-check` and `just mobile-test` pass: 4229 passed, 40
skipped.
- **Simulator run (iOS 27.0 simulator, iPhone 18 Pro, Block organization
dart-defines) against desktop 0.7.7 on `buzz.block.builderlab.xyz`:**
pairing completed (desktop reported the phone paired; identity
transferred; community saved) instead of hanging until the pairing relay
closed. The app then showed the organization sign-in banner and opened
browser sign-in for block.builderlab.xyz, as expected. Okta in the
simulator requires FastPass, so the final relay connection after sign-in
was not exercised there.
- Human device testing is still pending.

## Follow-up

- Test on a real phone with an organization build. The simulator
couldn't complete Okta FastPass, so the relay connection after
organization sign-in still needs checking.

---------

Signed-off-by: Spencer Lewis <slewis@squareup.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-03 17:17:15 -08:00
..