Triage the 60 unguarded broad-catch sites the #674 gate records in cancellation-catch-backlog.tsv

[monkopedia-coder]

The #674 gate (PR #720) discovers 60 broad catch clauses in production source sets with no preceding cancellation clause, recorded in scripts/cancellation-catch-backlog.tsv. This issue is their tracking home.

Why this issue exists

#720's backlog rows originally cited #667, which was closed COMPLETED on 2026-09-02 — and was scoped to its own six app/src/main sites, never to this list. #674 itself closes when #720 merges. Without this issue the entire backlog would cite two closed issues on the day it landed, invisible to any open-state triage filter, in a file whose own header says its purpose is not to become "the place things go to be forgotten."

(My error: I told #720's author that #667 was the natural consumer for these findings. It was already closed when I said it.)

The work

Each row needs triage, and the triage is not "add a cancellation clause to all 60."

Reachability first, severity second. A try whose guarded call never suspends cannot take delivery of a CancellationException at all — such a site is latent, not live, and a mechanical fix adds noise without removing risk. This distinction has already produced one false finding in this repo: #667's own sweep tabulated what each catch body does without a column for whether the exception can be delivered, and two separate readers independently read that as a list of live defects. It was not.

So for each row establish, and record:

1. Can the guarded call actually deliver cancellation? Does anything inside the try suspend? Is the enclosing scope ever cancelled?
2. If yes — live. Add the cancellation clause before the broad one and fix the ordering.
3. If no — latent. Say why in the row's reason, and it stays as documented debt rather than becoming a churn PR.

Useful discriminators in this codebase: does the scope ever get cancelled; does the guarded call actually suspend; is the state written observable after teardown. All three produced "latent, not live" verdicts on #667.

Notes

• IllegalStateException is the dangerous member of the broad set — CancellationException extends it on the JVM, so the clause reads as narrow and deliberate while catching exactly what the author believed they had excluded.
• Source order is the only enforcement. Kotlin diagnoses neither an unreachable nor a mis-ordered catch clause. A suspend function compiles to multiple exception-table ranges, and a guard correct in one is not automatically correct in another — Stop renewal auth providers swallowing cancellation (#670) #673 adjudicated a hard case by reading the compiled exception table, which is the standard if a row is genuinely ambiguous.
• Work in batches with real review. Sixty mechanical edits in one PR is not reviewable, and this defect class has already survived six separate human sweeps (Propagate cancellation out of the tunnel's returned results (#646) #660, AddIntegrationDestination swallows the cancellation #660 just made propagate, and OnboardingFlow's safe window is undocumented #662→Stop AddIntegrationDestination swallowing cancellation (#662) #665, Push-endpoint reporters swallow session-scope cancellation as a send failure #666→Stop push-endpoint reporters swallowing cancellation (#666) #669, FirebaseRenewalAuthProvider swallows worker cancellation as a token-fetch failure #670→Stop renewal auth providers swallowing cancellation (#670) #673, TunnelSessionManager's broad catch would re-swallow the TLS defect #616/#630 made visible #638→Stop TunnelSessionManager swallowing the TLS defect (#638) #672, Six catch sites in app/src/main swallow cancellation — all latent, one coupled to an invariant nothing enforces #667) precisely because each pass was scoped to what the last one missed.
• As rows are fixed, remove them from the TSV — the gate fails if the ledger claims a site the tree no longer has, so the file cannot silently rot.
• See The #674 ledgers are uncapped: a new violation can be silenced by one appended line #721: the ledgers are currently uncapped, so a new violation can also be silenced by appending a line. That is a separate defect in the gate's enforcement, not in this debt.

Related: #619, #661, #674, #720, #721.

[monkopedia-coder]

The 60 rows this issue triages land in PR #720, in scripts/cancellation-catch-backlog.tsv, each citing this issue.

Two things worth knowing before working the list:

• The ledger is an exact-match ratchet in both directions. Fixing a site fails the gate until its row is lowered or removed, so a fix and its bookkeeping land together. Moving a row to cancellation-catch-allowlist.tsv with a reason is the expected outcome for anything found non-deliverable — that is a completed triage, not an evasion.
• A measurement for ordering the work. I built a variant of the scanner that skips sites whose enclosing fun is not suspend and which sit in no lambda — structurally sound, since straight-line non-suspend code has no suspension point and production runBlocking is already gated by Eliminate production runBlocking: reactive preferences via StateFlow, async DI factories #136. It excluded only 10 of the 61. Those 10 are the cheapest reachability clearances to write up first; the remaining 50 need the real per-site argument.

Heaviest concentrations: McpRouting.kt (16), CertRenewalFlow.kt (4), then OutreachMcpProvider.kt / NotificationCaptureService.kt / TestRelayFixture.kt / NotificationIntegration.kt at 3 each.