[fix] the second dictation of a session stops inheriting the first one's socket

[YJack0000]

Reported from a device on build 28: the first dictation works end to end; from the second onwards it fails — either Connection failed. Please try again., or a pane that comes up listening to nothing.

Diagnosed by reading, with two of the three links confirmed by throwaway tests against a local WebSocket server (written, run, deleted — not in this diff).

A relay leg from the previous session could speak into the next one

handle(_:from:) guards on eventLeg == leg, which protects a session from the legs it has already replaced. But launch() reset leg to 0 for every session, so the previous session's first leg and this session's first leg carried the same number, and the guard could not tell them apart.

That matters because of which ending abandons a live socket. finishUp() — the successful ⏹ path, i.e. the one the user actually takes — did relay = nil with no cancel(); fail(), cancel() and endSessionWithMicTaken() all cancel. SttRelayClient.finish() sends the finalize frame and deliberately leaves the socket open for the drain, but it also cancels the keepalive and the liveness watchdog, so afterwards nothing keeps that connection alive and nothing kills it. It sits there holding a closure that publishes .closed whenever the relay eventually idles it out.

A backgrounded process runs no main-actor work until something resumes it — and the thing that resumes it is the next parley://dictate. So the stale obituary was routinely delivered into the session that had just replaced it:

1. .closed arrives tagged leg 0; the new session is also on leg 0 → guard passes.
2. handle reads it as this session's socket dying → scheduleReconnect().
3. scheduleReconnect() cancels the current client.
4. If that lands while launch() is suspended on try await client.start(), the cancelled client's in-flight send throws → Connection failed. Please try again.
5. If it lands after .listening, the live socket is cancelled and the pane keeps drawing ⏹ over a connection that no longer exists.

The fix is that leg is now bumped rather than reset — which is exactly what captureGeneration already does eleven lines above it, for exactly this reason. The file's own comment at the capture generation says a status "published while giving up in the background can be delivered after the user's next tap"; the relay side had the same hazard and the comment claiming legs already handled it was wrong across sessions.

This makes the stale event unrepresentable rather than merely unlikely. Cancelling the socket sooner would not: readLoop's catch publishes .closed for a deliberate teardown exactly as readily as for a dead peer, so cancelling changes when the stale event is emitted, not whether.

finishUp() now cancels the relay anyway, for a separate reason — every successful dictation was leaving a connection for the relay to time out at its leisure.

Every leg is now id-prefixed, including the first. leg == 0 ? nil : … was only ever an economy, and there is no leg 0 any more.

The keyboard decided once whether it could hear the app

All four DarwinObservers were registered inside a viewDidLoad test of hasFullAccess, while viewWillAppear re-read the same value on every appearance — with a comment saying it does so because the value changes. The file contradicted itself.

The window is not a corner case, it is the main path: iOS kills this extension almost every time the user bounces to the app (the code says so, in drainDownlink's own comment), so the second dictation is always served by a freshly loaded keyboard whose viewDidLoad ran during an app switch. One that read false there kept a working-looking voice pane — taps still mint sessions — while hearing no downlink, no window note, no readiness and no presence. The transcript would then only move on the next appearance, and ⏹ would look like it did nothing until the liveness watchdog fired ~25 s later.

Arming is now idempotent and retried from every viewWillAppear.

Not a v1.15 regression

Worth stating plainly, since the previous two PRs were: git diff ios-v1.14..origin/main is empty for AudioCapture.swift, SttRelayClient.swift, RelayAudioBridge.swift, ReconnectPolicy.swift and CaptureRecovery.swift. The leg = 0 line dates to #285 (2026-08-20), the commit that introduced the reconnect ladder. The Live Activity work did not cause this and the requestRefused cache added in #395 was verified to hold across sessions — end() deliberately does not clear it, so the budget is one Activity.request per foregrounding, not per word.

What this does not fix

Two of the three reported shapes are addressed; one is not.

• Connection failure and the session hangs — both explained above.
• "I have to authorize again" — not resolved, because the code as written cannot produce it. launch() only reaches requestPermission() on .undetermined, and the keyboard will not mint a session at all unless the readiness mailbox says micGranted. So either "authorize" means the trip through Parley / the Full Access notice (which the keyboard fix above would explain), or the grant is genuinely being lost. One question settles it: did iOS itself pop its grey "Parley would like to access the microphone" alert, or did the keyboard send you into Parley or into Settings?

Also unresolved and unresolvable from this repository: whether the relay caps concurrent feature=voice_typing streams per account. If it does, the leaked sockets above were hitting it, and the socket hygiene in this PR fixes that too — but confirming it needs relay-side logs from parley-internal.

The structural finding behind all of this

ios/App/project.yml declares three targets and no test target. DictationCoordinator, AudioCapture and KeyboardViewController all live in app/extension targets, so all 422 ParleyKit tests exercise value types only. There is no test covering any second-session path and structurally there cannot be one.

That is why this class of bug — "works once, then stops" — keeps being found on a device rather than in CI. #328, #281, #360, #348 and now this one are the same shape. Worth its own ticket.

Verification

• xcodegen generate + xcodebuild -scheme Parley -configuration **Release** -destination generic/platform=iOS → BUILD SUCCEEDED.
• swift test --package-path ios/ParleyKit → 422 tests, 1 skipped, 0 failures.
• Simulator: the app builds, installs and launches on an iPhone 17 Pro sim, but the bug cannot be reproduced there — transcription needs a signed-in account and the hosted relay, and parley://dictate is intercepted by simctl's own confirmation dialog. Said plainly rather than implied: this fix is verified to compile and to be consistent with the code around it, and is not verified to resolve the founder's symptom on hardware.

🤖 Generated with Claude Code

[github-actions]

✅ SonarQube Quality Gate passed — pathorsAI_parley

0 open issues on this PR.