fix(examples): capture the connector response on the two showcase REST ping flows

[os-help]

Fixes #7542

What was wrong

TaskCompletedRestPingFlow and ShowcaseDeclarativeConnectorPingFlow in examples/app-showcase/src/automation/flows/index.ts both told the reader that the call and its { status: 'ok' } response were captured on the flow run. Neither flow declared any variables at all.

run.output is not a free side effect of dispatching. The engine collects it from the flow's declared isOutput variables only — AutomationEngine.execute, "Collect output variables":

const output: Record< string, unknown > = {};
if (flow.variables) {
    for (const v of flow.variables) {
        if (v.isOutput) output[v.name] = variables.get(v.name);
    }
}

So both flows dispatched fine and returned an empty run.output, while the comment said the response was there — which sends the next reader hunting for an engine bug that does not exist. The sibling ShowcaseMcpConnectorEchoFlow is the proof it was authoring and not engine: same dispatch path, one declared variable, captured output.

The fix

Route 1 from the issue (the preferred one): declare the output variable both flows were evidently meant to carry.

The name was derived from what the step actually produces, not copied from the contrast fixture. connector_action writes a node's handler output back under ${nodeId}.${key} (engine.ts), the rest connector's request action returns { status, ok, body } (packages/connectors/connector-rest/src/rest-connector.ts), and both flows' connector node id is ping — so the response payload is ping.body. showcase_status_api is materialized by the same createRestConnector bundle through createRestProviderFactory, so the declarative flow is identical in this respect.

variables: [{ name: 'ping.body', type: 'json', isOutput: true }],

The comments were tightened alongside to name the variable, so the claim and the declaration cannot drift apart again.

Route 2 (weaken the comments) was measured and rejected: the capture works perfectly for these flows once asked for — see the verification below.

Verification — runtime capture, not schema validity

New file examples/app-showcase/test/connector-ping-run-output.test.ts. It drives the real flow definitions imported from src/automation/flows/index.ts through a real AutomationEngine with the real connector bundles — createRestConnector for the plugin rest connector, and createRestProviderFactory fed the real StatusApiConnector metadata for the ADR-0097 instance. Only fetch is stubbed, so the handler's { status, ok, body } output shape is the shipped one. The assertion is a content pin on the captured value:

expect(result.output).toEqual({ 'ping.body': { status: 'ok' } });

This is the runtime-capture level, not the schema level — an actual run of both flows, with the response value pinned. A booted app was not needed.

Reverse verification (predicted direction: red, with an empty output) — the fix was taken out with a path-scoped git checkout origin/main, never git stash:

FAIL  showcase_declarative_connector_ping captures it too, through the materialized ADR-0097 instance
AssertionError: expected {} to deeply equal { 'ping.body': { status: 'ok' } }
- { "ping.body": { "status": "ok" } }
+ {}

3/3 red, and the two dispatch cases fail with run.output = {} — the issue's reported symptom reproduced verbatim — while the recorded outbound request was still there, confirming dispatch itself was never the defect. Fix restored: 3/3 green.

Full local runs:

• pnpm --filter @objectstack/example-showcase test → 18 files, 171 tests passed
• pnpm --filter @objectstack/example-showcase typecheck → clean
• pnpm --filter @objectstack/example-showcase validate → exit 0 (only pre-existing unrelated warnings)
• node scripts/check-nul-bytes.mjs → OK

Notes

• Changeset: none. examples/app-showcase is private: true and publishes nothing, so this is the skip-changeset label route (label applied on this PR).
• Scope: src/system/connectors/ is untouched — that is batch-mate 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's baseUrl fix. origin/main was merged before opening this PR. The test reads StatusApiConnector but asserts only the flow-owned path (/api/v1/health), so it stays green across an env-overridable baseUrl.
• Checklist: docs/qa/platform-checklist/areas/automation.json (connector-dispatch-matrix) asserts that the rest ping and declarative ping both record GET /api/v1/health → {status:'ok'}. Under route 1 that clause becomes true as written, so it needed no edit — route 2 would have required changing it.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 11, 2026 8:58am