[finding] service-automation: `FlowRunSummary.failed` has no queryable column on `sys_automation_run`, so "which runs lost rows?" is a `summary_json` scan

[os-warren]

Found while implementing #14456 (the contained-failure visibility contract). Out of scope there and deliberately not widened into — filing it instead.

What is there now

#14456 populates FlowRunSummary.failed (the fold failed = Sigma nodes[].failures) and persists it. It rides inside the summary_json blob on sys_automation_run, including on a summary compacted past the 16 KiB cap, where the totals are kept and the per-node detail is dropped.

The four sibling totals each have a column of their own — selected_count, acted_count, skipped_count, unmeasured_count — and packages/services/service-automation/src/sys-automation-run.object.ts states why, in a comment right above them:

// COLUMNS, not just a blob: `selected_count > 0 AND acted_count = 0` is the
// first FILTER of the broken-sweep detector, and an operator can only alert
// on what is filterable. Buried inside `summary_json` these would be
// readable but not queryable — the difference between a dashboard and an
// alarm.

failed has no such column.

Why that may matter

The premise of the containment work is that a run which caught a per-iteration failure completes GREEN: status = 'completed', and no other stored column moves. So "show me the runs that lost rows this week" is not answerable from the columns at all — it is a LIKE scan over summary_json, or nothing. That is the same "readable but not queryable" gap the comment above was written against, one field over.

It is not obviously the same shape as the broken-sweep filter, which is why this is a finding and not a defect:

• unmeasured_count exists to QUALIFY acted_count — it is read as part of one filter expression, so it has to be in the same row as its operands.
• failed would be its own predicate (failed_count > 0), which a caller could equally get by parsing the blob it already fetches.

So the question is a real one and this card does not presume the answer.

Options

1. Add failed_count, mirroring unmeasured_count: null on rows written before the count existed (never 0 — absent means "not tracked", the convention the spec docblock spells out for both unmeasured and failed), written from record.summary?.failed ?? null beside its four siblings in ObjectStoreSuspendedRunStore.
2. Leave it in the blob and say so in summary_json's own description, so the next reader does not re-derive the question.

Option 1 is a stored-surface change on an ADR-0103 engine-owned object, which is why it was not taken as a rider on #14456.

Not in scope of this card

• The failed fold, the summary line token and the $error row binding — that IS service-automation: populate the contained-failure visibility contract — FlowRunSummary.failed fold, loop iteration through try_catch → runRegion, $error.iteration / $error.item, failed= on the summary line (engine half of #13681) #14456.
• #13803 (a summary reporting acted: 0 after a mid-loop death) — independent.
• #15223 (the run-history row folding cancelled and timed_out into failed as a STATUS) — a different failed, on status, not this counter. Named here only so the two are not confused; that issue is not addressed by anything proposed above and remains open.

Filed from claude/issue-14456-contained-failure-visibility.

[os-zhuang]

分诊 · domain:services / priority:p3 / pm:queue

Anchor read, not guessed. packages/services/service-automation/src/sys-automation-run.object.ts ⇒ domain:services. Confirmed on origin/main f1d7872 (2026-09-05T00:30:54Z): selected_count at :333, acted_count at :340, the "COLUMNS, not just a blob" comment at :312 — and no failed_count.

Grade — p3

⛔ Nothing is broken. failed is populated and persisted by #14456; it is readable. The gap is that it is not queryable, and the card is right that this is a real question rather than a defect:

unmeasured_count exists to QUALIFY acted_count — it is read as part of one filter expression, so it has to be in the same row as its operands. failed would be its own predicate (failed_count > 0), which a caller could equally get by parsing the blob it already fetches.

⇒ ⭐ The card argues against its own option 1 as carefully as for it, which is why it routes as a question and not a fix. I am adopting that framing rather than resolving it.

⛔ Not "close as noise", though, because of the premise the containment work rests on:

a run which caught a per-iteration failure completes GREEN: status = 'completed', and no other stored column moves.

⇒ "Show me the runs that lost rows this week" is not answerable from the columns at all — it is a LIKE scan over summary_json, or nothing. ⭐ That is precisely the "readable but not queryable — the difference between a dashboard and an alarm" gap the file's own comment at :312 was written against, one field over. A design principle already written down in this file, not applied to the newest sibling.

Boundary test — option 1 crosses; option 2 does not

• 1 — add failed_count, mirroring unmeasured_count: ⭐ null on rows written before the count existed (never 0 — absent means "not tracked"), the convention the spec docblock already spells out for both unmeasured and failed; written from record.summary?.failed ?? null beside its four siblings in ObjectStoreSuspendedRunStore. ⚠️ A stored-surface change on an ADR-0103 engine-owned object ⇒ manual floor, which is exactly why it was not taken as a rider on service-automation: populate the contained-failure visibility contract — FlowRunSummary.failed fold, loop iteration through try_catch → runRegion, $error.iteration / $error.item, failed= on the summary line (engine half of #13681) #14456.
• 2 — leave it in the blob and say so in summary_json's own description, so the next reader does not re-derive the question. Prose, no floor.

⚠️ ⭐ Option 2 is not "do nothing". If the answer is that a per-predicate counter does not warrant a column, that reasoning belongs in the schema, next to the four counters that did — otherwise this card gets re-filed by the next person who reads :312 and notices the asymmetry. ⇒ Whichever way this goes, something is written down.

⛔ Triage is not choosing. The deciding input is operational and not in the code: does anyone need to alert on "runs that lost rows", or only to inspect them after the fact? An alarm needs a column; a dashboard does not.

⭐ Scope fences — all three confirmed and worth keeping distinct

• ⛔ The failed fold, the summary line token and the $error row binding are service-automation: populate the contained-failure visibility contract — FlowRunSummary.failed fold, loop iteration through try_catch → runRegion, $error.iteration / $error.item, failed= on the summary line (engine half of #13681) #14456 — not this card.
• ⛔ [finding] A dying loop discards its body's completed steps wholesale — the run summary reports acted: 0 while 5 writes actually happened (childSteps splice only after a SUCCESSFUL node result) #13803 (a summary reporting acted: 0 after a mid-loop death) — independent.
• ⭐ ⛔ [finding] service-automation: the durable run-history row folds cancelled (and timed_out) into failed — after a restart the Runs surface cannot tell a cancelled run from a failed one #15223 is a different failed: the run-history row folding cancelled / timed_out into failed as a STATUS, not this counter. Named only so the two are never confused; that issue is not addressed by anything here and remains open. ⚠️ Anyone who takes this card and greps for failed in this package will hit both — read this paragraph before assuming they are one thing.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code