Stop routing production to a dead Temporal engine, and label container-tool launch failures

[imaustink]

Summary

The actual root cause of the recipe skill's ❌ fetch failed (found by checking the live cluster, not by guessing):

• agent-orchestrator's logs show agent engine: temporal (http://agent-controller-temporal-engine-gateway:8080) — every turn is forwarded over HTTP to a second service.
• kubectl describe pod on agent-controller-temporal-engine-gateway/-worker: both have sat in ImagePullBackOff for 6+ days. Their images (temporal-engine-gateway:latest, temporal-engine-worker:latest) have no registry prefix, so containerd resolves them against Docker Hub, which has never had them.
• This production environment has no Temporal cluster at all, and was never meant to route here — but charts/agent-controller/values.yaml (the umbrella chart's own default, per docs/adr/0036's rollout) sets agent-orchestrator.config.agentEngine: temporal and temporal-engine.enabled: true, and values-production.yaml never overrode either back off. Helm deep-merges the config map key by key, so simply not mentioning agentEngine in the production values silently inherited "temporal" from the base chart.
• Every turn was therefore forwarded to a gateway that has never once come up. The resulting dead-connection error is Node's native fetch() throwing with zero wrapping (TypeError: fetch failed), which propagated to chat verbatim — nothing recipe- or YouTube-specific about it.
• Fix: values-production.yaml now explicitly clears agentEngine/temporalEngineUrl and sets temporal-engine.enabled: false, restoring every turn to the in-process LangGraph loop this environment actually runs on. Verified with helm template against both values files — AGENT_ENGINE/AGENT_TEMPORAL_ENGINE_URL no longer render on the orchestrator Deployment, and no temporal-engine Deployment/Service/RBAC renders at all. Diffed the full rendered manifest before/after to confirm nothing else moved.

A real, separate bug also fixed here (found while investigating, kept because it's independently correct): apps/agent-orchestrator/src/agent/graph.ts's container-Tool (ToolRun/Job) branch of runTool had no catch around containerToolLauncher.launch()/its awaited result — unlike the agent-backed branch right above it. A failure launching a ToolRun (e.g. the k8s API call itself failing) would propagate uncaught out of the graph and hit server.ts's generic finish(\❌ ${err.message}`), losing all context about which tool or that launch (not the tool) failed. Now wrapped and labeled as tool failed to launch: `, with a regression test.

What I got wrong initially

My first pass diagnosed this as the k8s-launch gap above. That doesn't hold up: @kubernetes/client-node's HTTP layer (node-fetch) formats connection errors as request to <url> failed, reason: <cause>, not the bare string the user actually saw. Checked the live cluster directly this time instead of reasoning from code alone.

Test plan

• npx vitest run src/agent/graph.test.ts (138 passed, incl. new regression test for the launch-failure labeling)
• npx vitest run in apps/agent-orchestrator — 3 pre-existing failures in nats-agent-channel*.test.ts, confirmed unrelated (reproduce identically on main)
• npx tsc --noEmit — no new errors introduced
• helm template agent-controller charts/agent-controller -f values-production.yaml — renders cleanly, diffed full output before/after the values change
• helm upgrade against the live cluster — not run from here; flagging for confirmation before I (or anyone) applies this to production

🤖 Generated with Claude Code

https://claude.ai/code/session_01B5MkAovb1gWz4G34wSXaVC