[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

[os-sales]

Filed by the domain:services PM seat (session_01AUF1NoViznQK32gqpK8wS8) from the in-seat Clause-② contract review of PR #14388 (#13648), non-blocking follow-up 4 (verdict adopted verbatim on #13648). Recording only, unassigned, for first-touch grading. Pre-existing on origin/main; PR #14388 does not touch it.

The reading (at PR #14388's head 8ed17503; line numbers re-taken at fix time)

While tracing the engine-built up-bubble negative control (a delegated child completing and resuming its parent through engineBuilt(...)), the reviewer observed that the up-bubble path in packages/services/service-automation/src/engine.ts around :4833 always emits the line "child run … is gone — continuing without child output", although on that path the engine-built signal does carry the child's output (the parent's downstream captured the mapped subResult in the same test). The text describes a degraded case that did not occur.

What is asked

Make the line say what happened: log the "gone — continuing without child output" text only on the branch where the child run is actually unavailable and no output is carried, and say nothing (or a debug-level line naming the carried output) on the normal up-bubble. No behaviour change; level stays as it is (the #13398-class ruling applies to any level change through a published sink shape).

Boundary

Observed by reading the code path and the pin in src/builtin/screen-resume-signal-less.test.ts (case (c)); not driven at runtime beyond that test. Dup search over open cards found no card for this line.

Refs: #13648 · PR #14388 · #14379 (the delegated-child refusal handling, adjacent but a different defect).

[huangyiirene]

Triage: bug · priority:p3 · pm:queue · domain:services · type Bug. First grading, finding comes off. Named landing point, reproducible from the tree ⇒ queueable.

Confirmed on origin/main @ 5c9e40a, and worth writing down precisely, because a first reading of this code refutes the card and the second one vindicates it. The line is now at engine.ts:4813-4816. It sits in an else, so at a glance it looks branch-correct — "it only fires when the child is gone". It is not, and here is the mechanism:

const childRun = await this.loadSuspendedRun(childRunId);   // :4782 — SUSPENDED runs only
if (childRun) { …resume the child, take its output… }       // :4783
else { logger.warn("… is gone — continuing without child output"); }   // :4813

On the engine-built up-bubble the child has already completed, so it is not a suspended run, so loadSuspendedRun returns nothing and the else is taken — while the incoming signal already carries the child's output, because the engine built it that way. So the warning fires on the healthy path, and its second clause is simply false: the parent is continuing with the child's output, which is why the parent's downstream captures the mapped subResult in the same test the reviewer cites.

⇒ Both halves of the sentence mislead, in different degrees. "is gone" is true of the suspended-run lookup and false of the child (it finished); "continuing without child output" is false outright.

The discriminator to fix it on is not "is the child gone". ⛔ Do not branch on a second loadRun lookup — that reintroduces the same confusion one call over. Branch on whether the incoming signal already carries the child's output (the engine-built case), which is the fact the message is actually about:

• signal carries the child's output ⇒ this is the normal up-bubble; say nothing, or a debug line naming the carried output;
• no child run and no carried output ⇒ the genuine degraded case; keep the existing sentence and level.

Two fences. ⛔ The log level does not move — the #13398-class ruling covers any level change through a published sink shape, and this card's warrant is the text, not the level. ⛔ No behaviour change: the else branch must still continue the parent, exactly as today.

Why p3. Log-only, no user-visible behaviour, no data at risk. It is worth fixing rather than filing away because it is the cry-wolf shape: an operator who sees "child run is gone" on every healthy subflow completion stops reading the line, and the one time it means what it says is the time it gets ignored.

Pin it on the branch, not on the sentence. The existing case (c) in src/builtin/screen-resume-signal-less.test.ts already drives the engine-built path; the assertion to add is that the degraded sentence is absent there, plus a positive control that it still appears when no child run and no carried output exist. A test that only asserts the new text would pass with the branch still wrong.

⛔ Adjacent but different, and not to be folded in: #14379 (the delegated-child RETRYABLE refusal treated as terminal). That one is a real behaviour defect on nearly the same lines; two cards, two PRs, or the log fix disappears inside it.

Size/model suggestion: XS, sonnet.

---

Generated by Claude Code