[bug] A chat turn is bound to the request — navigating away can lose the reply while its tool side effects persist

[serge-ivo]

The question

Send a chat message (typed or spoken), then navigate away before the reply lands. Does the turn
still complete?

Finding: a Loop is durable, a plain chat turn is not

Loops are safe. POST /loop writes an agent_loop_runs row and a server-side driver runs it.
InstanceDetail.tsx:292 states the design outright: "The console used to BE the loop… That died
with the tab and could not be budgeted, because the platform did not drive it. Now the workflow
drives and this only reports", and "the run itself is durable and carries on regardless of
whether this tab can see it." Correct, and exactly right.

A plain chat turn has none of that. AgentDO.handleChat awaits this.think(...) and returns
the reply inline. There is no ctx.waitUntil, no blockConcurrencyWhile, nowhere in
agent-do.ts — the whole turn hangs off the inbound request. Nothing keeps it alive if the
client goes away.

Why the failure is worse than "you lose the reply"

The assistant message is only appended after think() returns. But tools execute during it,
and their side effects are already committed — memory writes, created tasks, a filed GitHub issue,
a started pipeline, a start_work handoff.

So an interrupted turn can leave: work done, nothing in the transcript. Come back and the
conversation shows your message and no reply, while the agent has in fact acted. The next turn is
then built from a history that contradicts what happened — and the honesty rules in the system
prompt cannot help, because the record itself is wrong.

This is the same class the codebase already fixed once for partial failures: #24 added
partialToolLog so a late-round error still surfaces the side effects that landed. That guard runs
inside the catch. A cancelled request never reaches it.

Worth checking before fixing

Confirm empirically whether Cloudflare actually cancels the DO's in-flight work when the client
disconnects, or whether it runs to completion. The absence of waitUntil means it is unprotected
either way, but the fix differs: if it already completes, this is a documentation and
status-reporting matter (#252). If it is cancelled, the turn needs to survive the request.

Reproduce: send a message that triggers a slow tool round, close the tab immediately, then re-read
the thread via GET /v1/instances/:id/messages and the activity log. If activity shows tool calls
with no assistant message, it is cancelling.

If it is cancelling

Detach the turn from the request. The platform already has the pattern — a durable run row plus a
driver (agent_loop_runs, the Loop). A chat turn could take the same shape, or at minimum be
wrapped so the DO finishes and persists the reply even after the client is gone.

Verification

• Send → navigate away mid-turn → the assistant message is present on return.
• Tool side effects and the transcript never disagree.

[serge-ivo]

Fixed in 400725d.

Verified true, claim by claim: POST /loop really is durable (row + AGENT_LOOP Workflow + a per-minute stale-run sweeper); agent-do.ts has zero waitUntil/blockConcurrencyWhile; the assistant message is persisted only after think() returns (:390), with no incremental write; all four callers (console, /v1/agents/:id/chat, trial chat, and the WS path) await the same inline handleChat; there is no agent_chat_runs table and no chat workflow; partialToolLog exists and runs only inside the catch.

On the open empirical question — whether Cloudflare cancels the DO's in-flight work on client disconnect — nothing in the repo pins that behaviour either way, and I could not settle it without a deploy. So the fix is the one the ticket calls the minimum, and it is correct under either answer:

• The turn is now a promise the DO owns (runTurn), started by the request and kept alive past it (keepAlive → ctx.waitUntil where the runtime offers it). A connected caller still awaits it and sees exactly what it saw before; it simply no longer owns the work.
• Each turn writes an in-flight marker (one storage key per turn, so concurrent turns can't clobber) and deletes it in a finally.
• A marker whose turn is missing from the DO instance's live set means the object restarted under it or the work was killed. That is reaped into a system message saying the turn was interrupted and that its actions did land — so "work done, nothing in the transcript" stops being silent, which is the part that made the next turn reason from a false record. Reaped on the next turn and on /state, so a returning reader learns without having to send another message.
• /state now reports inflight, which is what [bug] Navigating back loses 'working on it' — the run is still going and the API already reports it #252 uses to answer "is it working?" honestly.

Decisions are pure and unit-tested in lib/chat-inflight.ts (12 tests).

A fully durable chat run (run row + driver, like agent_loop_runs) remains the bigger option if the empirical answer turns out to be "cancelled and the reply is still lost" — but that is now observable rather than invisible, which is what it wasn't before.