AgentWorkflow's cached agent stub cannot survive a mid-run DO reset — step retries all fail and onWorkflowError is silently lost #1918

Summary

AgentWorkflow resolves its agent Durable Object stub once per run() execution (_initAgent → this._agent = await getAgentByName(...)) and every RPC path reuses that cached stub via the this.agent getter. If the agent DO is reset while the workflow is running — e.g. Error: Durable Object reset because its code was updated, which the platform can trigger even without a user deploy — that stub is permanently broken, and the workflow cannot recover:

1. Step retries are doomed. Every retry of an in-flight step that calls this.agent.* (including ThinkWorkflow's step.prompt submit) reuses the same dead stub and fails instantly with the identical error until the retry budget is exhausted and the instance errors.
2. Error reporting is silently lost. _autoReportError → notifyAgent → this.agent._workflow_handleCallback goes through the same broken stub, and its failure is swallowed (catch (_notifyErr) {}), so the agent's onWorkflowError never fires. From the agent/UI side the workflow just vanishes.

Observed in production

agents@0.14.2, a ThinkWorkflow instance on Cloudflare Workflows. The agent DO was reset mid-run (no deploy of ours matched the window — the last deploy was ~1.5h earlier). The next step.prompt submit step failed with Durable Object reset because its code was updated., and all 6 engine retries over 5 minutes failed instantly with the byte-identical error (each attempt duration 0s — the RPC never left the broken stub). onWorkflowError never fired on the agent, so no failure ever reached our workflow-tracking DB rows or connected clients.

Name:      diagnose-and-persist:submit-1
Success:   ❌ No
│ 12:30:44 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │
│ 12:30:54 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │
│ 12:31:14 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │
│ 12:31:54 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │
│ 12:33:14 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │
│ 12:35:55 │ 0 seconds │ ❌ Error │ Error: Durable Object reset because its code was updated. │

Still present in current main (packages/agents/src/workflows.ts): _initAgent assigns this._agent once and no RPC path re-resolves on a disconnected-stub error.

Why this seems worth fixing in the SDK

The SDK already treats this reset class as a first-class transient on the Agent side — isDurableObjectCodeUpdateReset is exported, and recent fixes (#1617, #1659, #1730) specifically recover scheduled callbacks and chat recovery from it. The workflow-side stub is the remaining gap, and it defeats one of the main reasons to use Workflows: the engine's own step retries would succeed if each attempt got a fresh stub, because the reset window is only seconds long.

Suggested fix

On an RPC failure matching isDurableObjectCodeUpdateReset (or isPlatformTransientError), re-resolve the stub with the already-captured init coordinates (getAgentByName(env[binding], name) / the facet-origin path) and retry the call once — or simply re-resolve per step attempt. submitMessages already carries an idempotency key, and the _wrapStep callbacks are idempotent, so a single retry is safe.

Workaround we're using

A subclass that overrides _initAgent at the prototype level and wraps the resolved stub in a self-healing Proxy: string-keyed method calls that reject with a code-update reset re-run the upstream _initAgent with the originally captured args and retry once; symbol-keyed members (notably Symbol.dispose, which _disposeAgent calls fire-and-forget) pass through synchronously. Happy to upstream a PR along these lines (re-resolution inside AgentWorkflow itself, using the exported classifier) if that direction sounds right.