Expose a submission retry to clients that read the conversation stream

[rikbrown]

Observed behaviour

A Cloudflare Durable Object can reset during a direct submission, for example with "Durable Object reset because its code was updated" after a deployment. The coordinator claims the submission again and resumes it from the persisted context. The recovery works, but a client that reads the conversation stream cannot see it:

• The retry continues the same response message from its durable anchor. The stream shows no output from the reset until the retry writes its next step. In one test that gap was 36 s.
• A tool call that was running when the object reset settles with the {"type":"interrupted","message":"Tool execution was interrupted before completion. The outcome is unknown."} marker.

A chat UI keeps its "working" state for the full gap. It cannot tell the user that the reply stopped and continues from the last completed step.

Cause and code location

processSubmission emits submission_running with attemptCount and maxAttempts, and the coordinator emits submission_recovery. Both go only to observe() subscribers on the server. The attempt that processSubmission passes to session.processSubmissionInput holds only submissionId and attemptId, so the code that writes the response (runPersistedContextInput) cannot tell a retry from a first attempt. Both functions are in dist/conversation-stream-store-*.mjs in 2.1.1.

Proposed change

Pass the attempt count to the session. When an attempt after the first resumes a response that already has output, write a message data part with { attemptCount, maxAttempts } to that response:

 // processSubmission
-			submissionAttempt: attempt
+			submissionAttempt: { ...attempt, attemptCount: submission.attemptCount, maxAttempts: submission.maxAttempts }

 // runPersistedContextInput
 				await this.beginResponseOutput();
+				const retry = options.submissionAttempt;
+				if (retry?.attemptCount > 1 && this.responseHasCompletedStep)
+					this.enqueueMessageDataWrite("replyAttempt", { attemptCount: retry.attemptCount, maxAttempts: retry.maxAttempts });

beginResponseOutput adopts the earlier attempt's durable anchor, so responseHasCompletedStep is true when the earlier attempt left an assistant message. An attempt that left none has no anchor for the part, and the client's pending state already covers that case. The part name is only an example; a name chosen by the package works as well.

A smaller alternative: only pass attemptCount and maxAttempts in the submission attempt, and let the app write its own part.

Environment

@flue/runtime 2.1.1, Cloudflare coordinator, durability.maxAttempts at its default of 10.