`try?` on the delivery path — five defects, one symptom, complete silence

[liversedge]

From PinPointStudio's preview handover, 28 August 2026, §4.2.

Why this is a defect class and not a style note

Five separate defects sat on the preview delivery path — an unreachable .present, an unchunked payload, a redundant openChannel, a duplicate stream_open, a shed reaching back before opened_at. Every one produced the identical symptom: a black tile on the host, and complete silence at both ends. Each only became visible once the one in front of it was cleared, which is what turned a delivery bug into two days.

⛔ They were silent because each error was swallowed by try?. Their conclusion, and ours: try? on anything that puts bytes on a link is a defect, not a style choice.

What is actually there, surveyed at 2f604b1

File	try?
Sources/App/HostLinkSession.swift	18
Sources/App/AppModel.swift	10
Sources/Platform/Capture/LivePreview.swift	2
Packages/Core/Sources/CaptureCore/Live/PreviewProducer.swift	1 (in a comment)
Packages/Core/Sources/CaptureCore/Ppcp/DevicePeer.swift	1 (hasStream, deliberate)

The ones that write to the link are the ones that matter — HostLinkSession.swift:280, :412, :429, :465 all try? await pump.perform { … } around a peer call.

⚠ Not all of them are wrong. try? await Task.sleep, a resourceValues read for a file size, and DevicePeer.hasStream's deliberate guard let handle = try? handle() are fine. This is an audit, not a sweep: the question for each is "if this throws, does anything anywhere ever find out?"

⚠ LivePreview.swift:63 now carries the corrected record at the site — "delivery used to be try? from end to end … that cost two evenings on 27-28 Aug 2026" — and the three counters that replaced it. That treatment has been applied to one file. This issue is the rest of the path.

Exit criterion

Every try? on a path that puts bytes on a link either propagates, or records a named reason where §2.8's per-stage counters can show it. A line-by-line pass with a note at each site saying which it is — including the ones deliberately left alone.

[liversedge]

One file done, the count went up, and two files joined the table

LivePreview.swift carries the corrected treatment — the record at the site and the three counters. Nothing else on the list has been touched, and the 29–30 August wired work added more.

File	At 2f604b1	At 2460d92
Sources/App/HostLinkSession.swift	18	21
Sources/App/AppModel.swift	10	11
Sources/Platform/Capture/LivePreview.swift	2	2
Packages/Core/…/Live/PreviewProducer.swift	1 (in a comment)	1 (in a comment)
Packages/Core/…/Ppcp/DevicePeer.swift	1 (deliberate)	1 (deliberate)
Sources/Platform/Network/WiredPresenceListener.swift	—	2
Sources/Platform/Rendezvous/PairingSecretStore.swift	—	2

⚠ The new ones are not all wrong, and two of them are on a link path. HostLinkSession.swift:354 is the wired connect burst — addSyncTimebase + syncTrigger(.connect), best-effort by the same argument as :322, and that argument is written at the site. :468's try? PairingSecretStore.rename(…) is a store write, not a link write. WiredPresenceListener.swift:330's guard let transport = try? await listener.accept() else { return } ends an accept loop on any error — worth deciding whether a listener that stops accepting should say so, given that the symptom is the phone silently looks un-wired on the cable, which is the one failure mode 8201ec8 spent a day chasing.

⛔ This is the argument for doing the audit rather than deferring it. The count moves every time someone builds on this path, and each new site is a place a future failure gets to be silent. 8201ec8 had to add PpcpLog before two wired faults could be diagnosed at all — the same lesson this issue is made of, arrived at again from a different direction.

Exit criterion unchanged: a line-by-line pass, a note at each site saying which it is, including the ones deliberately left alone.

[liversedge]

Half done — the payload path speaks, and it found real faults the same evening

The five stacked defects this issue was raised for were on the delivery path, and that part is converted:

• The drain loop (6a52651). It read (try? await hosted.pump.perform { … }) ?? 0, turning any throw into nil, nil into zero bytes, zero bytes into a 20 ms sleep, and retrying for ever — a clip that could never encode retried silently fifty times a second while the host read transfer: pending. The throw is caught and logged; drain started / drain stopped bracket it, because a loop that never began and a loop that began and threw were indistinguishable; NOT started names the silent no-op; STALLED fires on work queued and nothing moving for five seconds.
• serveCaptureRequest (97133f1), the one function in the chain with no voice at all — five guards that all returned in silence. It now says which: no hosted link, no video Stream, no detection sink, a t0 that will not convert, or an announce that threw. ⛔ That announce was itself behind a try?, so an announce could fail and leave the host waiting for a Capture that had been cut and persisted.
• The recording error surface (c848b95). One translation — AppModel.userFacing — turns every recording error into words for a person and sends the raw error to the app log, instead of an armed screen reading channelClosed(CaptureCore.ChannelCloseReason.peerClosed) over a ring running at 238 fps.

⭐ Two real leads surfaced within an hour of the path being given a voice, and both were invisible before: announce WITHOUT payload firing twice per hosted row, and 86 pump FAILED libppcp: output buffer too small in a single run. Filed separately.

⛔ What is left, and it is the larger half

Sources/App/HostLinkSession.swift still carries 27 try? and Sources/App/AppModel.swift 12. Most are try? await pump.perform { … } — the pattern this issue is about, applied to every link write in the file.

⛔ reportResidual is still the sharpest of them (HostLinkSession.swift:806): the whole conversion, syncResidual write and record are inside one try? … ?? nil, on the single number REQ-SYNC-4 exists for. #28 has now measured a residual through it — a swallowed failure there returns nil, which is indistinguishable from 8.2i1's legitimate "no relation to work with".