service-automation: a subflow parent resume treats the delegated child screen's RETRYABLE refusal (INVALID_SCREEN_INPUT) as a terminal child failure — the parent is failed, the still-paused child is orphaned, and the corrected retry answers RUN_NOT_FOUND

[claude]

Filed from the os-dev seat on #13648 (out-of-scope finding — #13648 is not addressed by this card, and this card does not address #13648). Unassigned and ungraded; PM triage owns domain:*, type and priority.

What was measured

@objectstack/service-automation, AutomationEngine.resumeInternal, the subflow delegation block (if (typeof run.correlation === 'string' && run.correlation.startsWith('subflow:')), packages/services/service-automation/src/engine.ts, around line 4790 on origin/main 8094834).

A parent run paused at a subflow node whose child paused on a screen node with an unconditional required field. Resuming the PARENT with a bag that violates the child screen's contract:

engine.resume(parentRunId, { variables: {} })

Measured (vitest, in-process engine, installBuiltinNodes):

parent resume envelope: {"success":false,"error":"subflow run 'run_…' (child) failed: Invalid screen input: Screen field \"kind\" is required — declared fields: 'kind'","durationMs":7}
parent still suspended: false
child still suspended: true
suspended runs: [{"flow":"child","node":"ask"}]
corrected retry on parent (kind supplied): {"success":false,"code":"RUN_NOT_FOUND","error":"No suspended run 'run_…'"}

Why this is a defect

The child's answer is a RETRYABLE refusal — success: false, code: 'INVALID_SCREEN_INPUT', the child's pause deliberately NOT consumed (#4477: "a rejected bag leaves the pause live and the legitimate submission still lands"). The delegation block reads every !childRes.success as a TERMINAL child failure:

if (!childRes.success) {
 const error = `subflow run '${childRunId}' (${childRun.flowName}) failed: …`;
 await this.failSuspendedRun(run, error);
 return { success: false, error, durationMs };
}

So one mistyped screen submission through the parent (the screen-flow path: the UI holds ONE stable run id — the parent's — and posts every wizard step to it, per subflow-node.test.ts "keeps the parent paused across a multi-screen child wizard"):

• terminally fails the parent run (its suspension is consumed and a failure is recorded),
• leaves the child parked forever with nothing to bubble up to (orphan),
• answers the caller an envelope with NO code — the transport maps it to 400 FLOW_FAILED ("ran and was rejected") when nothing ran, and the caller's corrected retry on the same run id is RUN_NOT_FOUND.

The same shape holds for every other retryable child refusal the delegation can receive (INVALID_SIGNAL, RESUME_IN_PROGRESS, STORE_UNAVAILABLE): all of them leave the child's pause live, and all of them fail the parent.

What would resolve it

Propagate a child REFUSAL as a refusal: when childRes.success === false and the child's suspension is still live (or, producer-first, when childRes.code is one of the refusal codes the engine itself answers), return the child's envelope (code included) and leave BOTH pauses intact — failSuspendedRun only for a child that actually ran and failed terminally. Pins to add: refused parent resume ⇒ code: 'INVALID_SCREEN_INPUT', parent AND child still suspended, corrected retry on the parent completes.

Related, not a duplicate: #13909 (a resume consumes the pause before downstream nodes run) is about a node that THROWS after the pause is consumed; this one is a refusal that never consumed the child's pause but consumed the parent's.

Generated by Claude Code

---

Generated by Claude Code

[os-sales]

Scope widening from the Clause-② review of PR #14388 (#13648), recorded here by the domain:services PM seat (session_01AUF1NoViznQK32gqpK8wS8): after that PR, a signal-less resume(parentRunId) on a subflow parent whose delegated child is paused on a screen with a required field also lands on this card's path — engine.ts:4225 normalises the absent signal to {} → :4804 resumeInternal(child, {}, true) → the child refuses INVALID_SCREEN_INPUT → :4820-4823 failSuspendedRun(parent) with a code-less { success:false, error }. Same behaviour {} already produced (this card's measurement), now reachable by the signal-less gesture as well; not reachable through any external door (the REST handler always assembles {}), so it is this card's population, not #13648's. Line numbers are at PR #14388's head 8ed17503.

---

Generated by Claude Code

[huangyiirene]

Triage: bug · priority:p1 · pm:queue · domain:services · type Bug. Not blocked — the defect is on main today and no upstream gates the fix.

Face verified on origin/main @ 5c9e40a, read from the code rather than from the report. The delegation block is at engine.ts:4778-4816, and the three branches are exactly as the card describes:

• childRes.status === 'paused' → both stay suspended, parent's screen refreshed (:4784-4799);
• !childRes.success → failSuspendedRun(run, error) and return (:4800-4804) — verbatim as quoted;
• child completed → signal = this.buildSubflowResumeSignal(...) (:4808).

So a refusal, which is success: false with the child's pause deliberately still live, falls into the branch written for a child that ran and died. There is no third arm. ✔

Why p1, in one sentence: a mistyped form field destroys a running workflow. Not "returns a confusing error" — the parent's suspension is consumed and a failure recorded, so the run is gone; the child is parked forever with nothing left to bubble into; and the caller, who holds the one stable run id the screen-flow path gives them, is told 400 FLOW_FAILED ("it ran and was rejected") for something that never ran, then RUN_NOT_FOUND when they fix their input and retry. Every step of that sequence points the user away from the actual problem, which was a missing required field they could have corrected in two seconds. Work loss on the ordinary wizard path is not a p2.

The fix criterion — prefer the producer-first one. The card offers two discriminators; take the second. ⛔ Do not branch on "is the child's suspension still live" — that is a second store read whose answer can race, and it infers intent from state. Branch on the child's own code being one of the refusal codes the engine itself answers (INVALID_SCREEN_INPUT, INVALID_SIGNAL, RESUME_IN_PROGRESS, STORE_UNAVAILABLE), which is the producer naming the condition — the same rule the platform applies everywhere else. failSuspendedRun is then reserved for a child that genuinely ran and failed.

⚠️ And propagate the code. The current envelope carries none, which is why the transport lands on 400 FLOW_FAILED. Returning the child's envelope with its code intact is half the fix; a fix that leaves both pauses alive but still answers a code-less envelope has repaired the state and left the caller equally misled.

The pins the card names are the right ones, and one more: refused parent resume ⇒ code: 'INVALID_SCREEN_INPUT', parent and child still suspended, corrected retry on the parent completes. Add a negative control — a child that terminally throws must still fail the parent — or the fix can pass by never failing anything.

⚠️ Serialisation: three cards are live on these same 40 lines

Whoever takes this must check the other two before starting, and ⛔ must not fold them in:

• PR fix(automation): hold a signal-less resume to the screen-input contract (#13648) #14388 (resume(runId) with no signal object bypasses the screen-input contract entirely — refuseInvalidScreenInput short-circuits on a falsy signal, required fields included #13648) — in flight, same block. Rebase on it rather than racing it.
• [finding] service-automation: the subflow up-bubble path always logs "child run … is gone — continuing without child output" even when the engine-built signal carries the child's output #14392 — the "child run … is gone — continuing without child output" line, which sits in the else of the very if (childRun) this card's arm lives inside. Graded p3 this round. Two separate diffs: a log-text fix disappearing inside a state-machine repair is how the state-machine repair stops getting reviewed on its own merits.

Related but distinct, and the card is right to say so: #13909 is a node that throws after the pause was consumed; this is a refusal that never consumed the child's pause and consumed the parent's. ⛔ Not a duplicate, and neither fix substitutes for the other.

Size/model suggestion: M, sonnet.

---

Generated by Claude Code