You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8c7cca1
Browse filesBrowse the repository at this point in the historyBrowse files
fix(approvals): keep an undifferentiable stranded row in the report, and stop a malformed host verdict aborting the scan (#16739)
Three residues of the #15358 contract review (#16709).
Item 1 (test-only) — the restore verb's drop of a stale hot consumed-suspension
copy was unpinned package-wide: the reviewer's E2 ablation deleted the
behaviour and left the whole service-automation suite green. Pinned where the
drop is distinguishable from a no-op — after the durable row that proves the
copy stale is evicted by run-history retention, a kept copy would be the only
witness left and would offer an operator a restore of a run that already
COMPLETED on another replica.
Item 2 (PM ruling, 2026-09-08) — a thrown third read counted `undetermined`
and dropped the row. By the time that oracle is asked the first two have
already answered (no live pause, terminal `failed`); it is asked only WHICH of
the three shapes the row is, so a read that could not be made is exactly the
"could not differentiate" case `'failed'` already means. The row now stays in
the report; `undetermined` is kept as telemetry.
Item 3 — `refineFailedRunState(verdict)` ran outside the `try`, so a host
resolving `undefined` threw a `TypeError` out of `inspectStrandedRequests` and
the scan enumerated nothing. The refinement now runs inside that `try`: a
malformed verdict costs its own row the differentiation and no other row
anything.
No new `StrandedRunState` member and no widened export.
Claude-Session: https://claude.ai/code/session_012zTkyNHJ7TkuN2oXtP5x37
Co-authored-by: Claude <noreply@anthropic.com>
`inspectStrandedRequests` no longer drops a row it could not differentiate, and no longer lets one misbehaving host abort the whole scan (#16709, items 2 and 3).
6
+
7
+
Both are the same mistake at two altitudes: the method exists to **enumerate** the terminal approval requests whose flow run cannot advance, so a failure to read the #15358 third oracle must never remove a row from the answer — and never remove the *other* rows either.
8
+
9
+
-**A thrown third read now leaves its row in `stranded`, as `'failed'`.** It used to be counted `undetermined` and skipped, exactly as a thrown `hasSuspendedRun` or `getRun` is. Those two are not the same question: a throw from either leaves it unknown *whether* the row is stranded at all, and a storage outage must not be published as a lost run. By the time the third oracle is asked, both have answered — no live pause, terminal `failed` — and it is asked only *which* of the three shapes the row is. A read that could not be made is therefore the textbook "could not differentiate", which is what `'failed'` already means (`StrandedRunState`, #15358 ruling item 1). Dropping the row let `stranded: []` read as "nothing stranded" while a row was in fact stuck, with a log line as its only trace; for a report, fail-closed means showing the row.
10
+
-**A host that violates `ApprovalResumeSurface` no longer aborts the scan.**`refineFailedRunState(verdict)` ran outside the `try` that wrapped the read, so an implementation resolving `undefined` where a verdict is declared threw a `TypeError` out of `inspectStrandedRequests` itself and the scan enumerated **nothing**. The refinement now runs inside that `try`; a malformed verdict costs its own row the differentiation, is counted `undetermined`, and costs every other row nothing.
11
+
12
+
⛔ No new `StrandedRunState` member and no widened export: both cases map onto the existing undifferentiated `'failed'`. The `undetermined` counter is kept as telemetry and now **overlaps**`stranded` by design — a row can be both reported and counted — so neither number alone sizes the scan's blind spot.
0 commit comments