Stream and Cancel Agent Responses Without Unsafe Retries
Qualified HealthSoftware Engineer · OnsiteLast updated
Design SSE or WebSocket streaming, end-to-end stop handling, and safe Agent retries while distinguishing local cancellation from provider billing and tool effects.
Design streaming, cancellation, and failure recovery for a multi-turn Agent/RAG conversation system. Users must be able to stop generation, while the call chain can include an orchestrator, a model, vector retrieval, and external tools with side effects.
The source requests immediate interruption of the model call and billing when a user clicks Stop. Explain which parts can be controlled locally and which require explicit provider support.
Constraints & Assumptions
- Streamed text may already have reached the client before cancellation or failure.
- A closed browser connection does not by itself prove that remote generation stopped.
- Tool operations may write data or charge money, so arbitrary retries can duplicate effects.
- The source supplies no universal provider cancellation, refund, request-lookup, or idempotency guarantee.
Clarifying Questions to Ask
- Is server-to-client token delivery sufficient, or is bidirectional interaction on one connection required?
- Does the provider expose cancellation and authoritative request status, and what happens to in-flight billing?
- Which tools are read-only, idempotent, or irreversible?
- Should a stopped turn remain as partial history, and can a later retry create a new attempt?
Part 1 — Stream and Stop
Compare SSE and WebSocket for this application. Trace a stop request from the UI through stream delivery, orchestration, model execution, and pending tools.
What This Part Should Cover
- Protocol choice based on traffic direction and operational behavior.
- An authorized cancellation operation identified by session, turn, and attempt.
- Immediate local suppression versus confirmed upstream cancellation and billing uncertainty.
Part 2 — Recover the Agent Chain
Describe deadlines, retries, durable operation identity, and partial outcomes when a component times out or crashes.
What This Part Should Cover
- Different retry treatment for retrieval and side-effecting tools.
- Attempt fencing and a recorded canceled, failed, complete, or uncertain outcome.
- No duplicate tool effects caused by blindly replaying an entire agent turn.
Hints
Hint 1
Stop delivery and stop computation are separate: The server can stop sending bytes even if the provider has already accepted a long-running request. Decide how that uncertainty should appear in durable state.
Follow-up questions
- What happens when completion and cancellation arrive at the same time?
- How should a reconnecting client distinguish a stopped attempt from a fresh retry?
- Why is replaying the same prompt not sufficient to deduplicate a tool charge?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.