Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Knowledge catalogChoose core direction and segmented content
Understand → Implement → Debug → Design
Reconnecting clients and durable task state
Examine task and connection decoupling, event sequence number, reconnection and clear final state.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Your first model call and response contract →Idempotency, unknown outcomes, and task recovery →Which step do you want to learn from this knowledge point?
Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
Realize again
Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
View the code example →Will troubleshoot
Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Able to choose
Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →Knowledge unit directory
LEARN · PRACTICE · REFLECT
Knowledge learning and personal records
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Answers and personal notes
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Reconnecting clients and durable task state
Understand the core principles first
Preparatory concepts:Idempotent submission, event cursor, persistent state machine
The connection carries progress notifications, and task status is persisted by the backend. Reconnection only restores the observation position. Repeated submission, cancellation and business completion require independent and clear semantics.
A browser connection does not own the task
Refresh, network failure, or leaving a page does not establish cancellation intent. Submission creates a stable run_id; clients retain a submission key and reuse it after network failure. Backend execution continues while the connection displays events.
A cursor restores notifications
Event IDs locate a reconnection point only if replayable events are retained and clients deduplicate them. SSE Last-Event-ID does not recover every task or guarantee one business effect. Expired history needs an authoritative snapshot and new starting point, rather than endless requests for missing events.
Read terminal state independently
A lost completion event must not prevent querying task state and artifacts. A connected stream can accompany a failed task, so UI completion binds business state rather than stream closure. Cancellation uses a separate authenticated endpoint; committed effects still need reconciliation. This is general application design. MCP resumption applies within its own protocol, not as a requirement for every website.
Check understanding with a question
The Agent is still running after the web page is refreshed. How can I restore the progress without submitting the task again?
Tasks run independently of browser connections. Stable run_id and submission keys prevent duplicate creation. Persist progress events, retain cursors, and replay or return snapshots after reconnection. Disconnection does not imply task failure. UI completion requires authoritative terminal state and verified artifacts. Cancellation is explicit, not inferred from closing SSE or WebSocket.
Realization and trade-offs
Separate submission and subscription
POST verifies the identity, task parameters and client idempotency keys when creating a task. Submitting the same logic returns the same run, but reusing keys with different parameters should be rejected. Then subscribe to the event of run_id. User refresh only re-reads the running status and subscribes, but does not re-create the task. User permissions are checked when accessing tasks and events, and other people's logs cannot be read just by guessing the ID.
Events must be explainable
The event contains run_id, incremented serial number, type, time and necessary data, distinguishing stage progress, tool completion, waiting for approval and final status. The UI can display a user-facing summary of the stages without exposing model hidden reasoning or sensitive tool text. The order of writing event and task status must be consistent or can be reconciled to avoid the event being said to be completed but the artifact not yet submitted.
Reconnection, duplication and gaps
The client recovers from last_seq and deduplicates. Event retention expired returns a detectable gap and the client re-reads the full state snapshot with a watermark before continuing from the watermark. Slow clients use bounded buffers and cannot occupy unlimited memory. Transmission reconnection only restores observation and should not trigger re-execution of business steps.
Cancellation and Ending
By default, closing the page only closes the observation connection, and explicit cancellation requests are processed and propagated by the server. For submitted external action verification results, the final state may include partial completion or pending verification. Test disconnection, refresh, duplicate events, snapshot and event competition, cross-user subscription and end event loss, and confirm that the state finally seen by the user is consistent with the server facts.
code example
Client finds duplicate events and sequence number gaps
Only demonstrates the local event state machine and does not include authentication, server persistence, or real network transmission.
last_seq = 0
for seq in [1, 2, 2, 4]:
if seq <= last_seq:
print("duplicate", seq)
continue
if seq != last_seq + 1:
print("resync after", last_seq)
break
print("apply", seq)
last_seq = seq
expected output
apply 1
apply 2
duplicate 2
resync after 2Engineering deduction
- scene
- Interview hypothesis: The mobile phone switches to the background and the connection is disconnected. Re-open the page.
- design decisions
- Reuse the run_id, recover from the event water level, and do not resubmit the build task.
- Verify target
- The progress is continuous and there are no repeated tasks, and the final state comes from the server.
- applicable boundary
- Events can be restored through snapshots outside the retention period, and unlimited playback is not promised.
Continuous questions and answers
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1What should I do if the last completed event is lost?
After the task is separated from the flow, the loss of final state notification must be repaired.
Reference answer
Complete retained events after reconnection, or query authoritative task snapshots and artifact verification status. If the background is completed, return the completed version; if the stream expires, explicitly tell the client to continue from the snapshot. You cannot resubmit because the last event has not been received, nor can you treat SSE shutdown as a success.
Follow this answer further
Level 2The completion event has expired and the task artifacts have been cleared. How to express it on the page?
The parent supplements the notification through snapshots, and the child increases the scope of evidence after the retention period has expired.
Reference answer
Return the final state of the task and clear information that the artifact has expired; if the final state is no longer retained, it means that the completed content cannot be queried rather than fabricated. The record retention policy provides explicit operations for reinitiating new tasks, and does not silently convert cursor expiration into redoing old tasks.
Follow this answer further
Level 3When a user requests a rerun, may it reuse the original submission's idempotency key?
The parent asked to allow re-initiation and continued to clarify the identity difference between new tasks and network retries.
Reference answer
"Resend old request" and "create new task" should not be confused. Explicit redo generates a new commit key, records the association with the old run_id, and revalidates authorization and external write exposure; the old key still points to the old task. Users understand that new work will be generated, preventing refreshes from being accidentally repeated.
Level 1How to deal with the backlog logs of slow clients?
Progress persistence also requires resource and retention boundaries.
Reference answer
Equipped with bounded buffering, event retention and snapshot compression, key status and errors are retained first, and non-critical token-by-token logs can be merged. If the backlog exceeds the limit, it can be disconnected and snapshot recovery is required. Task execution is not delayed by infinite buffering; events cannot be silently lost and still claim to be seamlessly recovered.
Level 1Should closing the page automatically cancel it?
A user's connection status does not automatically express an intent to cancel the business operation.
Reference answer
Depending on the explicit product semantics, the default should differentiate between disconnection and cancellation. Interactive temporary sessions can have an explicit disconnect cancellation policy, while persistent tasks continue and allow the user to return. Cancellation requests must be authenticated, idempotent, and recorded; when external effects have occurred, cancellation can only prevent subsequent actions.
Draw inferences from one example: If the conditions change, how to deduce it?
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
Frequent switching of mobile networks
Changing conditions:The connection drops repeatedly but the task keeps running.
Extended question:How to avoid multiple creation?
Derivation and reference solutions
The client saves the same submission key and run_id, and the server atomically de-resubmits; reconnecting only allows the task to be queried with an event cursor. If the client loses the key, it will first be retrieved through the account task list, and the task identity will not be guessed based on the same natural language content.
The principles that remain unchanged:Repeated observations do not create new business tasks.
High-frequency token flow and low-frequency business status
Changing conditions:The volume of notifications is large and critical status needs to be saved for a long time.
Extended question:Are all tokens stored permanently?
Derivation and reference solutions
Temporary presentation and persistent business events are separated by purpose, key status and artifacts can be read back, and tokens are processed according to explicit retention policies. The client encounters a gap and cuts the snapshot; complete token playback cannot be used as the only basis for business recovery, and permissions and resource restrictions are still implemented independently.
The principles that remain unchanged:Authoritative task status is independent of presentation layer notification granularity.
Easy to make mistakes
- Refresh and submit again
- Success is displayed when the flow ends.
- Task ID as authorization credential
References
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
Check how far you understand
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
- Basic standards met
- You can separate the creation task and subscription progress, and refresh the page to only re-observe the task.
- Intermediate and advanced signals
- There are event serial numbers, deduplication, idempotent submission and permission verification.
- Senior Signal
- Consider snapshot water levels, slow consumers, retention periods, and final state consistency.
View verification records for independent examples
Hands-on verificationComplete on demand · Suggestions15 minutes
Design the client behavior when events 1, 2, 2, and 4 arrive to illustrate the recovery of missing sequence number 3.
Expand acceptance requirements and checkpoints
- Repeated events do not repeat rendering actions
- Gaps are detected instead of ignored
- Refresh does not create new tasks
Key inspections
- Task life cycle is independent of connection
- Ordered event deduplication and snapshot recovery
- Distinguish between cancellation and disconnection