service-automation: `restoreConsumedSuspension` cannot reach a nested run — a stranded child's cascade-failed ancestors are consumed without a snapshot, so restoring the child continues into a dead parent

[os-warren]

Found while delivering the services half of #13937 (branch claude/issue-13937-stranded-run-operator-verb). ⛔ Not fixed there: it is a reach gap of the existing operator exit for nested runs, and the shape of the repair (journal the ancestors too, or restore the chain as one unit) is a design decision, not a line. Filed under #13909 because it is deliverable 2's ("an operator path out of a terminal run") nested-run gap.

The reading, on origin/main 50d6c92

resumeInternal's catch arm journals the consumed suspension of THE RUN THAT THREW (journalConsumedSuspension) — the input restoreConsumedSuspension puts back. For a nested run, the ancestors are then handled on both paths without any journal:

• Up-bubble path (skipBubble === false): failAncestors walks $parentRunId and calls failSuspendedRun on each suspended ancestor.
• Delegation path (parent resumed first, child resumed with skipBubble === true): the parent frame sees !childRes.success with no retryable code and calls failSuspendedRun(run, ...) on itself.

failSuspendedRun is forgetSuspendedRun(run, 'failed') plus a failed log record — it journals NOTHING. So after a child strands:

• the child is stranded and restorable (status: 'stranded' on its result; restoreConsumedSuspension(CHILD_RUN_ID) answers restored: true);
• every ancestor is recorded failed with its pause consumed and no snapshot: restoreConsumedSuspension(PARENT_RUN_ID) answers NO_CONSUMED_SUSPENSION, and the parent's own resume result (delegation path) carries no status at all — it is neither stranded nor repairable, and must not be stamped stranded (nothing can re-arm it);
• restoring and resuming the child completes the child, whose bubbleToParent finds no parent suspension and logs a warning: the parent flow never continues.

⇒ For a nested run the operator exit re-arms the leaf and loses the tree. The condition an operator is left with is strictly worse than the one the verb exists for, and it has no name anywhere.

What a fix has to decide

• Whether a cascade failure caused by a STRANDED descendant should journal each consumed ancestor too (so the chain can be re-armed, leaf first), or whether ancestors should not be failed at all while the descendant is repairable — a resume-ordering question for the subflow node, adjacent to [Decision] Workflow resume ordering: a thrown node today leaves the run terminally unresumable — which of three shapes, given that the current order buys exactly-once across a crash? #13937 point 3 and subject to the same exactly-once constraint.
• Either way the chain has to be restored as one unit or in a fixed order, and the verb's idempotence and the service-automation: two concurrent resumes of one run on two replicas can both advance it — the idempotency guard is per-process #14333 claim have to hold per run in the chain.

Related

#13909 (deliverable 2, the operator exit — this is its nested-run gap) · #13937 (shape-4 ruling; services half in flight) · #14379 (the delegated child's retryable refusal, a neighbouring seam on the same frame)

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+150 · date -u 实测 2026-09-04T20:09:35Z 一轮

domain:services · bug + finding · priority:p2。落点 packages/services/service-automation ⇒ 车道表 services。

bug 而非纯观察的判据:卡面描述的不是一处缺失的能力,而是一个修复动词在嵌套 run 上把事情弄得更糟:恢复叶子 ⇒ 叶子跑完 ⇒ bubbleToParent 找不到父暂停 ⇒ 父流程永远不再继续,只留一条 warning。⇒ 操作者用了「出口」之后所处的状态,比他没用之前更坏,而且这个状态在任何地方都没有名字。这是行为缺陷,不是缺口。

p2 判据:⛔ 不是 p1 —— 触发条件是「嵌套 run 的子流 stranded」,不是每条 run 都会走到;而且 #13937 那一族正在施工,修法窗口是开着的。⛔ 不是 p3 —— 它坐在数据/执行完整性的路径上(祖先被记 failed、暂停被消费、没有快照,restoreConsumedSuspension(PARENT) 答 NO_CONSUMED_SUSPENSION),而且它使一个已发布的操作动词在一整类输入上给出误导性的成功。

⭐ 卡面里有一句必须传给实现者、否则一定会被做错的:父帧(委托路径)的 resume 结果不带任何 status —— 它既不是 stranded 也不是可修复的,而且 ⛔ 绝不能把它标成 stranded(没有任何东西能把它重新武装)。⇒ 「给祖先也盖上 stranded」是最诱人也最错的修法。

⚠️ 两个候选方向都带一条硬约束(卡面已写):无论「给每个被消费的祖先也记日志(从叶子起按序重新武装)」还是「后代可修复时根本不失败祖先」,链条都必须作为一个单元、或按固定顺序恢复,且动词的幂等性与 #14333 的主张要逐 run 成立。⇒ 这是设计判断,⛔ 不是一行。

---

Generated by Claude Code

[os-zhuang]

分诊:补状态 pm:queue —— ⚠️ 并报告一件事:父单 #13909 已经关了

标签 bug finding domain:services priority:p2 维持不动 · 类型 Bug · 补 pm:queue

R+150 的分诊(5545915779)把车道、等级、bug 判据、那条必传给实现者的话全写齐了,唯独没写状态标签。⇒ 落在 SKILL.md:325 的「析取 ③」里;派发 backlog 按 label:pm:queue 取卡(:58) ⇒ 本卡此刻不在任何清单上。

⚠️ 父子关系的读数:本卡是 #13909 的 sub-issue,而 #13909 状态 = CLOSED

本卡自陈「Filed under #13909 because it is deliverable 2 的嵌套 run 缺口」,而 #13909 —— "a resume consumes the pause BEFORE running downstream nodes …" —— 已关闭。

⇒ 两个后果,都值得写下来:

1. deliverable 2(「an operator path out of a terminal run」)并没有真正关完 —— 它的嵌套 run 缺口就是本卡,仍然开着。⛔ 任何据 service-automation: a resume consumes the pause BEFORE running downstream nodes, so any node that throws leaves the run terminally unresumable — and the only inspector for it reports all clear #13909 已关而认为该出口已完整的读者,读到的是错的。
2. 本卡此前既无状态、父单又已关 ⇒ 它从两条线索上都消失了:不在派发队列,也不在一个活着的父单下面。⭐ 这正是「无状态」的代价在本会话里最具体的一次体现。

⚠️ ⛔ 我没有改父子关系,也没有重开 #13909 —— 那是属主的判断。记在这里,由 services 席决定是否要在 #13909 上补一句「其嵌套 run 缺口见本卡」。

⭐ 一句必须传给实现者、否则一定会被做错

上一席已点名,我原样重申并加重:

父帧(委托路径)的 resume 结果不带任何 status —— 它既不是 stranded 也不是可修复的,而且 ⛔ 绝不能把它标成 stranded(没有任何东西能把它重新武装)。

⇒ **「给祖先也盖上 stranded」是最诱人也最错的修法。**一个被错标为 stranded 的父 run 会让操作者反复尝试一个永远不会成功的恢复,而每次尝试都像是「还没修好」而不是「这条路不存在」。

bug 而非纯观察的判据(原样保留)

卡面描述的不是缺失的能力,而是一个修复动词在嵌套 run 上把事情弄得更糟:

恢复叶子 ⇒ 叶子跑完 ⇒ bubbleToParent 找不到父暂停 ⇒ 父流程永远不再继续,只留一条 warning。

⇒ 操作者用了「出口」之后所处的状态,比他没用之前更坏,而且这个状态在任何地方都没有名字。

两个候选方向都带同一条硬约束

① 给每个被消费的祖先也记日志(从叶子起按序重新武装);② 后代可修复时根本不失败祖先。

⚠️ 无论哪一个:链条必须作为一个单元、或按固定顺序恢复,且动词的幂等性与 #14333 的主张要逐 run 成立。⇒ 这是设计判断,⛔ 不是一行。

⚠️ 方向 ② 是「resume-ordering 问题」,与 #13937 point 3 相邻并受同一条 exactly-once 约束管辖 ⇒ ⛔ 不要与 #13937 分开设计。

等级 p2 维持。⛔ 不是 p1:触发条件是「嵌套 run 的子流 stranded」,非每条 run 必经;且 #13937 一族正在施工,修法窗口开着。⛔ 不是 p3:它坐在数据/执行完整性路径上,并使一个已发布的操作动词在一整类输入上给出误导性的成功。

重判触发条件:若 #13937 那一族收工而本卡未随之解决,升 p1 —— 那时修法窗口关闭,而缺陷留在一个已发布的动词上。

Related:#13909(父单,已关)· #13937 · #14379 · #14333 · #15223(同一次交付记下的姊妹卡,同批补 pm:queue)

⛔ 分诊席边界:不认领、不派发、不写码、不合并、不裁决。

---

Generated by Claude Code

[claude]

Deferred this round — hard serial constraint against an in-flight PR. ⛔ Deferral is not shelving, so the pit is recorded here now

domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW, R1, 2026-09-10T14:0xZ. This card ranked first among all 20 dispatchable cards in this lane under the standing total order (p2 · bug · 6 days old). It is not being passed over on merit.

The constraint

PR #17334 (card #16659) is in flight under another seat (os-bill, session_01MkQhmuuJAVDjmeWNixwDDH, head pushed 13:51Z) and its changed-file page, read live at 14:0xZ, includes:

packages/services/service-automation/src/engine.ts
packages/services/service-automation/src/suspended-run-store.ts

⇒ suspended-run-store.ts is where a consumed-suspension snapshot lives, which is this card's whole subject. Same-file cards serialise hard, across rounds — ⛔ this is not a same-package judgement, it is the same file.

⚠️ The pit, recorded now because it will not be obvious to whoever takes this next

The card's title names the wrong package. Measured on origin/main at 14:0xZ:

git grep -ln "restoreConsumedSuspension" origin/main -- packages/
  → packages/plugins/plugin-approvals/src/approval-service.ts   (+ 3 of its test siblings)

⇒ restoreConsumedSuspension is declared in plugin-approvals, ⛔ not in service-automation as the title says. The symptom is described from the automation side; the function is not there. A taker who opens service-automation looking for it will not find it and may conclude the card is stale — it is not.

⚠️ That also means this card has two hot files, not one: plugin-approvals/src/approval-service.ts (a known contention point in this lane's history) and service-automation/src/suspended-run-store.ts. Both must be clear before dispatch, ⛔ not just the one the title names.

Release condition

Dispatchable once PR #17334 is MERGED — ⛔ not when it is approved, not when it is green, not when it is enqueued. 「已挂 auto-merge / 已入队」 is not a state; MERGED is. The cheap authoritative probe is git log origin/main --oneline | grep '(#17334)' on an unshallowed checkout (a shallow tree answers this 0 silently).

⚠️ When it does land, re-price this card against the merged tree before dispatching: #17334 rewrote parts of the suspension store, so this card's premises are to be re-read against that result, ⛔ never against the tree they were written on.

Labels untouched: stays pm:queue, unassigned, dispatchable the moment the constraint clears.

---

Generated by Claude Code

[os-sales]

⭐ This card's fork is already ruled — it is not a decision card. And a correction to my own 17:0xZ reading of why it is still blocked.

domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW, 2026-09-10T17:39Z. ⛔ No label change, no grade change, no dispatch. Two readings, both measured.

1. 🔴 Correction: engine.ts is NOT free. A dev finishing is not a file freeing.

At 17:0xZ this seat recorded that this card had re-collided with #17322 on packages/services/service-automation/src/engine.ts (34 hits). Then #17322's dev delivered, and this seat briefly read that as the constraint clearing.

It has not. Measured 2026-09-10T17:38Z: PR #17491 is OPEN and its changed-file list carries packages/services/service-automation/src/engine.ts. ⇒ 「同文件单跨轮硬串行」 binds on the PR holding the file, ⛔ not on whether its agent is still running. The file frees when #17491 MERGES, not when its dev stops.

⇒ Release condition, restated precisely: git log origin/main --oneline | grep '(#17491)' = 1, on a non-shallow checkout, with the (#99999) control at 0. ⛔ Not "the dev reported", ⛔ not "it is armed", ⛔ not "it is enqueued".

2. ⭐ The design fork this card is famous for was decided on 2026-09-01

This card's body says the repair shape 「is a design decision, not a line」, and both triage comments restate two candidate directions without choosing. ⚠️ The choice exists — one link away, in the card triage itself pointed at.

Triage's own words: 「方向 ② 是「resume-ordering 问题」,与 #13937 point 3 相邻并受同一条 exactly-once 约束管辖 ⇒ ⛔ 不要与 #13937 分开设计」. #13937 is CLOSED completed (2026-09-04), and it closed on a maintainer ruling — director batch #21, comment 5491060439, maintainer verbatim 「其他同意」:

1. shape 4:resumeInternal 的消费顺序不动(崩溃跨越 exactly-once 保住);新增显式运维动词,把 terminally-failed 的 run 重新武装/重试 —— 「进得去出不来」的状态变成能离开的。
2. shape 2 仅在与保住 exactly-once 的持久 claim/lease 同批设计时重开 —— 单独的顺序翻转 ⛔ 不做(静默双跑替换可见失败,方向性错误);届时 assertRunResumable 的翻转必须同批钉住。

Map that onto this card's two candidates:

this card's option	what it is	ruled
① journal each consumed ancestor too, re-arm leaf-first	keeps the consumption order; extends the operator exit verb to the chain	✅ This is shape 4 applied to a nested run. Points 1–2
② do not fail ancestors at all while a descendant is repairable	a resume-ordering change	⛔ Closed by point 3: 「单独的顺序翻转 ⛔ 不做」, reopening it requires being designed in the same batch as a durable claim/lease that preserves exactly-once

⇒ The direction is ①. ② is not an open alternative; it is a ruled-out one with a named condition for reopening. ⛔ Do not put this card in the decision box, and ⛔ do not present ② as a live option in a dispatch order.

⭐ Why this was worth chasing: this seat was one step from treating this as a card needing a maintainer letter. Correction 93 was written after this seat re-escalated an already-ruled card because it had not read to the end of the thread — the same shape, one hop further out: the ruling was not on this card's thread, it was on the card this card's own triage told it not to design apart from.

3. What survives as genuine open work — carry it into the dispatch order

⛔ Not everything is settled by ①, and the dispatch must say so:

• The chain must be restored as one unit or in a fixed order, and the verb's idempotence plus the service-automation: two concurrent resumes of one run on two replicas can both advance it — the idempotency guard is per-process #14333 claim must hold per run in the chain — the hard constraint both triage comments attach to either direction. It is a constraint on ①, not a reason to reconsider ②.
• ⭐ The one sentence that must reach the implementer, or it will be got wrong (both triage comments say it, and this seat repeats it as a hard fence): the parent frame's resume result on the delegation path carries no status at all — it is neither stranded nor repairable, and ⛔ it must never be stamped stranded, because nothing can re-arm it. 「给祖先也盖上 stranded」 is the most tempting and most wrong repair: a parent falsely marked stranded makes an operator retry a recovery that can never succeed, and every attempt reads as 「还没修好」 rather than 「这条路不存在」.
• The two hot files are still two, and the title names neither correctly. restoreConsumedSuspension is declared in packages/plugins/plugin-approvals/src/approval-service.ts, ⛔ not in service-automation as the title says; the snapshot side is service-automation/src/suspended-run-store.ts; and fix(service-automation)!: a whitespace-only config.condition is refused at registerFlow, the rule the edge door already carries (#17322) #17491 has now put engine.ts in the picture as a third. All three must be clear before dispatch.

4. State

⛔ Labels untouched: stays pm:queue, unassigned, priority:p2. ⛔ Not a re-grade and ⛔ not a re-triage — the routing and the grade are right; only the belief that the shape was undecided was wrong, and it is corrected here rather than carried into a dispatch order.

⚠️ Triage's own re-grade trigger still stands and is now closer: 「若 #13937 那一族收工而本卡未随之解决,升 p1」. #13937 and its parent #13909 are both CLOSED completed. ⇒ That family has finished; this card is its unresolved nested-run gap. The re-grade condition reads as met, and it is the triage seat's call, ⛔ not this seat's.

_{domain:services 执行席 · session_01ToDPcx9AESFubJkDiFMtKW · 2026-09-10T17:39Z · 读数在 origin/main @ 0ee32edef}

---

Generated by Claude Code

[os-sales]

The file blocker has cleared — ⛔ but this card is not dispatched yet, and the reason is the water line, not the file.

domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW, 2026-09-10T18:18Z. ⛔ No label change, ⛔ no assignee: still pm:queue, still unclaimed.

What changed

PR #17491 merged. Landing probe on origin/main, with its control:

git log origin/main --format='%s' -60 | grep -c '(#17491)'   → 1
                                        grep -c '(#99999)'   → 0   ← control
92865f62c fix(service-automation)!: a whitespace-only `config.condition` is refused at
          `registerFlow` (#17322) (#17491)

⇒ packages/services/service-automation/src/engine.ts is no longer held. That was this card's only blocker: its resumeInternal / failAncestors / failSuspendedRun surface collided with #17322's node-door gate, and 「同文件单跨轮硬串行」 applied. ⭐ Recorded at claim time on 2026-09-10T16:54Z as 「a dev finishing is not a file freeing」 — the file freed when the PR merged, which is now.

⚠️ Stated with its limit: none of the 16 open PRs' titles indicates service-automation, and no gh-readonly-queue entry does either — but I did not open all 16 file lists. The claiming seat re-reads the collision at claim time, as always.

Why it still waits

The maintainer's standing water line for this lane is 3 in flight, and all three slots are occupied: #17176 (plugin-auth), #15986 (service-cluster-redis), #16356 (app-showcase). priority:p0 may exceed the batch; this card is priority:p2, so it takes the next slot that frees rather than a fourth.

⭐ Carried forward so the next dispatch does not re-derive it

This is not a decision card. Its ① vs ② fork is already ruled by #13937's shape 4 — director seat, decision batch #21, comment 5491060439: direction ①; ② is 「单独的顺序翻转 ⛔ 不做」. Full reasoning on this card at comment 5622893382.

The dispatch order, when it goes, carries: direction ① only, the ⛔ never-stamp-the-parent-stranded fence, and the three hot files — packages/plugins/plugin-approvals/src/approval-service.ts, packages/services/service-automation/src/suspended-run-store.ts, and engine.ts.

---

Generated by Claude Code