Showcase flow comments overstate behaviour: `TaskCompletedRestPingFlow` / `ShowcaseDeclarativeConnectorPingFlow` claim the connector response is captured on the run, but neither declares an `isOutput` variable

[huangyiirene]

Symptom

The source comments on TaskCompletedRestPingFlow and ShowcaseDeclarativeConnectorPingFlow claim that "the call and its {status:'ok'} response are captured on the flow run".

They are not. Both flows dispatch correctly, but run.output is empty — neither flow declares an isOutput variable, so nothing from the connector call is ever surfaced on the run.

The comment is the damaging part. A reader — human or agent — takes it as a statement of platform behaviour and concludes that connector responses are captured automatically. When run.output then comes back empty, the natural reading is "the engine dropped the response", and the next step is to go hunting in the connector dispatch path for a bug that does not exist. The engine is fine; the fixture simply never asked for the value. A comment that describes behaviour the code does not implement is worse than no comment, because it redirects debugging away from the real cause.

This is an authoring gap, not an engine one, and the sibling fixture proves it: the MCP connector flow does declare an isOutput variable and its run output is captured correctly (upper=OBJECTSTACK). Same engine, same dispatch path, different fixture — one asks for the output, two do not.

Root cause

TaskCompletedRestPingFlow and ShowcaseDeclarativeConnectorPingFlow declare no isOutput variable. run.output is therefore legitimately empty, and the source comments describe an outcome the flows do not arrange for.

Fix — either direction, but do both halves of whichever you pick:

1. Add the isOutput variable to both flows, matching what the MCP connector flow already does. This makes the comments true and makes the response genuinely inspectable on the run. Preferred: it is what the fixtures were evidently meant to demonstrate.
2. Or correct the comments to say the response is not captured — and in that case also fix the checklist clause that asserts capture, since it is written against the comment's claim rather than the code's behaviour. Correcting the comment while leaving the clause asserting capture just relocates the same contradiction.

Reproduction

1. Boot the showcase on an isolated file DB and port. (Note the connectors' hard-wired baseUrl will need working around on a non-3000 port — see the companion finding on StatusApi/StatusOpenApi.)
2. Trigger TaskCompletedRestPingFlow; repeat for ShowcaseDeclarativeConnectorPingFlow.
3. Read the resulting run → dispatch succeeded, but run.output is empty.
4. Trigger the MCP connector flow for contrast → run.output carries upper=OBJECTSTACK.
5. Compare the three flow definitions: only the MCP one declares an isOutput variable.

Re-check the fixtures:

rg -rn "TaskCompletedRestPingFlow|ShowcaseDeclarativeConnectorPingFlow" examples
rg -rn "isOutput" examples

Source

Extracted from the QA run #7516 (framework a86db17). Listed there as item 3 under "Fixture / authoring issues to fix"; it is what held connector-dispatch-matrix to PARTIAL.

[os-zhuang]

Findings triage — resolved the filing-time pm:queue+finding dual state to pm:queue (finding removed; the pair corrupts both the queue view and the finding stock — same resolution class as the 7 QA-wave duals handled last round).

• Grade rationale: concrete authoring defect with named fixtures, a scripted repro, a proving sibling fixture, and a stated preferred fix (add the isOutput variable both flows were evidently meant to carry). Nothing observation-class about it — dispatchable as filed.
• Premise verified on origin/main @ 744b8f5: in examples/app-showcase/src/automation/flows/index.ts, neither TaskCompletedRestPingFlow nor ShowcaseDeclarativeConnectorPingFlow declares isOutput (the nearest isOutput hit belongs to the next flow in the file, ShowcaseMcpConnectorEchoFlow — exactly the card's contrast fixture, variables: [{ name: 'echo.structuredContent', type: 'json', isOutput: true }]). Premise holds.
• Routing check: showcase automation fixtures exercise the flow/connector subsystem ⇒ filer's domain:services matches the domain table (examples/** belongs to the subsystem it exercises). Kept.
• Dedup: companion card Showcase REST connectors hard-wire baseUrl to http://127.0.0.1:3000, so self-ping flows fail fetch failed on any isolated instance — a port mismatch, not an egress block #7538 (hard-wired baseUrl) is the separate port-mismatch defect the repro notes; no overlap in fix site.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-help]

Claim: PM loop, services lane, wave 2 round 3
Session: session_015fkdTyGmMD5s8ZtEifvuGy
Branch: claude/issue-7542-showcase-flow-isoutput
Worktree: objectstack-issue-7542
Domain: domain:services
File surface: examples/app-showcase/src/automation/flows/index.ts (the TaskCompletedRestPingFlow / ShowcaseDeclarativeConnectorPingFlow declarations) + any flow-fixture test in the same app. Stop on breach.
Container & model: S-grade fixture repair with triage-verified premise, the contrast fixture named (ShowcaseMcpConnectorEchoFlow's isOutput: true variable), mode:subagent, model: opus.
Serial constraints cleared: ⚠️ batch-mate #7538 is in the SAME example app — fix sites are disjoint per triage's dedup (src/automation/flows/index.ts here vs src/system/connectors/* there). Region-level declaration is this line; both devs merge origin/main before opening their PR, and any conflict goes to the merge queue, not manual ordering. No open PR or other in-flight claim touches examples/app-showcase.

---

Generated by Claude Code