Symptom
The showcase's REST connectors — StatusApi and StatusOpenApi — declare baseUrl as the literal http://127.0.0.1:3000 in their providerConfig. The value is not env-overridable.
Any instance that does not happen to be listening on port 3000 therefore cannot self-ping: every flow that dispatches through these connectors fails with fetch failed. That is the normal case for CI, for QA runs, and for any local dev that boots on an isolated port — which is exactly the configuration these fixtures most need to work in.
The important part: this is a port mismatch, not the sandbox egress block. Those two failure modes present identically (fetch failed) and it is easy — and wrong — to write the failure off as "no outbound network in the sandbox" and stop. The run established causality: putting a throwaway TCP forwarder from 3000 to the instance's real port made the same flows succeed with no other change, giving clean before/after evidence that the destination address is the whole problem.
The cost is not just a red run. It teaches every reader of the showcase that connector baseUrl is a hard-coded literal, and it silently converts a fixture defect into an apparent platform/environment defect for anyone who hits it without the forwarder trick.
Root cause
Fixture authoring, not the connector engine — dispatch itself is proven working in the same run (the MCP variant dispatches and captures output end to end, and an unregistered connector gives a named refusal rather than a silent no-op).
The providerConfig for StatusApi and StatusOpenApi carries baseUrl: 'http://127.0.0.1:3000' as a literal, with no env indirection, so the value cannot follow the port the instance actually bound.
Two acceptable resolutions:
- Make
baseUrl env-overridable (read the instance's real base URL / port from the environment, defaulting to the current literal) so the self-ping fixtures work wherever the app boots. This is the better outcome — the flows become genuinely runnable and the fixture stops teaching a hard-coded address.
- Failing that, add a
knownGaps entry so the failure is declared rather than rediscovered. This is strictly the fallback: it makes the gap honest but leaves the clauses unrunnable.
Reproduction
- Boot the showcase on an isolated port (anything other than 3000), with an isolated file DB.
- Trigger a flow that dispatches through
StatusApi or StatusOpenApi.
- Observe the run fails with
fetch failed.
- Confirm it is the address and not egress: start a TCP forwarder listening on
127.0.0.1:3000 and forwarding to the instance's real port, then re-trigger the same flow. It succeeds, unchanged.
Re-check the literals:
rg -n "127.0.0.1:3000|baseUrl" examples --glob '*onnector*'
rg -rn "StatusApi|StatusOpenApi" examples
Source
Extracted from the QA run #7516 (framework a86db17). Listed there as item 1 under "Fixture / authoring issues to fix"; it partially blocks connector-dispatch-matrix.
Symptom
The showcase's REST connectors —
StatusApiandStatusOpenApi— declarebaseUrlas the literalhttp://127.0.0.1:3000in theirproviderConfig. The value is not env-overridable.Any instance that does not happen to be listening on port 3000 therefore cannot self-ping: every flow that dispatches through these connectors fails with
fetch failed. That is the normal case for CI, for QA runs, and for any local dev that boots on an isolated port — which is exactly the configuration these fixtures most need to work in.The important part: this is a port mismatch, not the sandbox egress block. Those two failure modes present identically (
fetch failed) and it is easy — and wrong — to write the failure off as "no outbound network in the sandbox" and stop. The run established causality: putting a throwaway TCP forwarder from 3000 to the instance's real port made the same flows succeed with no other change, giving clean before/after evidence that the destination address is the whole problem.The cost is not just a red run. It teaches every reader of the showcase that connector
baseUrlis a hard-coded literal, and it silently converts a fixture defect into an apparent platform/environment defect for anyone who hits it without the forwarder trick.Root cause
Fixture authoring, not the connector engine — dispatch itself is proven working in the same run (the MCP variant dispatches and captures output end to end, and an unregistered connector gives a named refusal rather than a silent no-op).
The
providerConfigforStatusApiandStatusOpenApicarriesbaseUrl: 'http://127.0.0.1:3000'as a literal, with no env indirection, so the value cannot follow the port the instance actually bound.Two acceptable resolutions:
baseUrlenv-overridable (read the instance's real base URL / port from the environment, defaulting to the current literal) so the self-ping fixtures work wherever the app boots. This is the better outcome — the flows become genuinely runnable and the fixture stops teaching a hard-coded address.knownGapsentry so the failure is declared rather than rediscovered. This is strictly the fallback: it makes the gap honest but leaves the clauses unrunnable.Reproduction
StatusApiorStatusOpenApi.fetch failed.127.0.0.1:3000and forwarding to the instance's real port, then re-trigger the same flow. It succeeds, unchanged.Re-check the literals:
Source
Extracted from the QA run #7516 (framework a86db17). Listed there as item 1 under "Fixture / authoring issues to fix"; it partially blocks
connector-dispatch-matrix.