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
Reconnect transport, recover messages, and reconcile business outcomes
Examine the differences between stdio, Streamable HTTP, session recovery and business idempotency.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Tool calls: structure, authorization, and business contracts →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.
Reading implementation and trade-offs →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 · Reconnect transport, recover messages, and reconcile business outcomes
Understand the core principles first
Preparatory concepts:JSON-RPC request matching, SSE cursor, Business idempotency
Transmission disconnection means that the message channel is interrupted, but does not mean that the business action is canceled or does not occur. Request ID matching response, event ID positioning message, business operation ID deduplication side effects; the three identities cannot replace each other.
Inspect three timelines
Connections open and close; protocol requests receive responses; business actions commit and take effect. A connection can fail before a remote action completes. Treating disconnection as business failure and resending immediately risks duplicate writes.
Resumption restores messages, not actions
The pinned MCP 2025-11-25 revision allows optional SSE replay using Last-Event-ID. Expired sessions require reinitialization rather than indefinite ID reuse. Associate late or repeated responses with their original calls; duplicate events are not new actions.
Persist operation identity across connections
Save operation IDs, parameter digests, and unknown states. Reuse business keys where idempotency exists, or query business status without message replay. HTTP retries and SDK reconnection do not guarantee exactly one effect. For stdio, stdout carries only protocol messages; log output can corrupt communication.
Check understanding with a question
The MCP connection is disconnected. Can I re-execute the last tool directly after reconnecting?
Disconnection does not prove non-execution. Separate transport reconnection, protocol session recovery, and business reconciliation. Where supported, resume events by cursor; reinitialize expired sessions; query write receipts by operation ID. New connections or JSON-RPC IDs do not establish idempotency. Retry decisions depend on tool semantics and target support, not only HTTP status.
Realization and trade-offs
Keep three kinds of identifiers distinct
The JSON-RPC request ID is used to match requests and responses, the session ID is used for protocol sessions, and the business operation_id is used to identify a logical action. The three life cycles are different. Restarting the client process may generate a new protocol ID, but the same pending operation should retain the business ID. Under stdio, it is also necessary to prevent logs from being written to stdout and polluting protocol messages. The logs should go through independent channels.
Recovery sequence after disconnection
First mark the local operation as unknown result, and suspend repeated submission of the same business action. If the server provides flow recovery capabilities, it will be restored from the confirmed event cursor; when the session is terminated by the server, a new session will be established according to the negotiation process. Restoring messages does not mean re-executing the tool. The client should deduplicate consumed events. If the response cannot be restored, check the results through the business query tool or operation ledger.
When are retries allowed?
Read-only queries can be retried on a budget; write operations can only be retried if the same idempotency key is supported downstream, or non-execution has been reliably confirmed. If there is neither an idempotent mechanism nor a query, it will enter manual verification or a clear unknown state, and it cannot promise to execute it exactly once. TCP connection closing, browser exit, and request cancellation are also not the same business signals.
Verification protocol and business layers
After the server submits the action and before the response is delivered, proactively disconnect, reconnect and observe whether repeated side effects occur. Also test for recurring events, cursor expiration, session expiration, and process restarts. The optional recovery capabilities in the specification need to be checked for actual server support, and the implementation of a certain SDK cannot be regarded as a capability that all MCP services have.
Engineering deduction
- scene
- Interview Hypothesis: The MCP publishing tool completed publishing, but the response stream was lost in network jitter.
- design decisions
- Keep the operation_id and restore the message or query the release receipt first.
- Verify target
- Reconnection does not generate a second release and remains in an unknown state if it cannot be verified.
- applicable boundary
- MCP alone cannot promise exactly-once execution without downstream idempotency or an outcome-query interface.
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 1Is Last-Event-ID a business idempotency key?
Different flags solve different problems, and mixed use may mistake recovery for re-execution protection.
Reference answer
No. Last-Event-ID tells the server the location of the stream event last received by the client for optional message recovery; the business idempotency key identifies the same logical operation and requires the execution end to support deduplication. Resume the same event or create a new session will not automatically avoid duplicate payments. Associate event consumption records with business operation ledgers, and manage message deduplication and side effect deduplication respectively.
Follow this answer further
Level 2The same success event is replayed twice. How can the client avoid repeated update tasks?
After clarifying the purpose of the cursor, you still need to deal with the failure window of repeated consumption by the client.
Reference answer
Record the consumption progress according to the server, session or flow scope and event ID, and then perform idempotent merge according to the operation ID when updating the business status. You can do this when the progress and local state are the same as when the transaction is committed; otherwise it may be consumed again after restarting, and the merge should still be safe. The event content is bound to the original call_id and cannot be misallocated to new requests.
Follow this answer further
Level 3The event has been received but the progress has not been reached and the library crashes. Where should recovery start?
Messages received are not atomic with local commits, and recovery correctness relies on safe replay.
Reference answer
Allows replay of already viewed events, starting from the last reliably saved cursor. The business state application remains idempotent and would rather read repeatedly than skip unknown events; if external side effects are triggered by consumption, independent key operations are required. When atomic saving is not possible, replay security must be designed, and "received" cannot be used as persistent evidence.
Level 1What should I do if the server does not support resume streaming?
When optional recovery is missing, business verification must exist independently.
Reference answer
Don't wait for protocol capabilities that don't exist. After establishing or reinitializing a authorized connection, check the business operation status first; read-only calls can be retried in a bounded manner, and write calls are determined by downstream idempotency support and verification results. Actions that cannot be queried or deduplicated are kept unknown and manually verified. The new JSON-RPC ID cannot prove that the old request was not executed.
Level 1What happens if the stdio service prints logs to stdout?
Transmission reliability is tied to the protocol format, communication errors still do not determine business facts.
Reference answer
Logs may be parsed as JSON-RPC messages, causing parsing errors or request-response mismatches. The protocol output is written to stdout, the diagnostic log is written to stderr or a separate log file, and the dependent library is prevented from writing the startup banner to stdout. When troubleshooting, distinguish between protocol parsing failures and business errors. Do not directly redo the write action due to parsing failures.
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.
The connection is not disconnected but the request times out
Changing conditions:Disconnect and switch to the client and wait for the budget to be exhausted.
Extended question:Can business processing be redone as a failure?
Derivation and reference solutions
No. Waiting for timeout and disconnection also only mean that the result has not been obtained locally. Query the original operation and continue according to the idempotent strategy; stopping the client to wait does not necessarily mean canceling the remote end. Cancellable tools require a clear cancellation request and receipt, and the submitted write must still be verified.
The principles that remain unchanged:Communication and wait states are not substitutes for business results.
Session terminated by server
Changing conditions:The session can be continued after reconnection, but the session has become invalid.
Extended question:Should old operation records be discarded with the session?
Derivation and reference solutions
Not lost. Establish new sessions by protocol and rediscover capabilities while preserving the query basis for old business operations. Session state may disappear, but external facts such as payments, releases, etc. still exist; new sessions only provide new channels. Confirm the tool version and permissions before processing the original unknown action.
The principles that remain unchanged:The business life cycle may be longer than the protocol session, and the operation ledger must be independent.
Easy to make mistakes
- Unconditionally resend if disconnected
- Treat JSON-RPC ID as business idempotency key
- Treat closing the connection as a cancellation action
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
- A disconnect can occur after the action has already committed.
- Intermediate and advanced signals
- Able to disassemble flow recovery, session reconstruction and receipt verification.
- Senior Signal
- Use fault injection to test duplicate events and conservative terminal states when outcomes cannot be reconciled.
Hands-on verificationComplete on demand · Suggestions15 minutes
Draw the timing sequence when the submission is successful but the response is lost, and list the three branches after reconnection.
Expand acceptance requirements and checkpoints
- Successful actions are not blindly repeated
- Unknown will be returned if verification is not possible.
- Event deduplication is separated from business idempotency
Key inspections
- Distinguish between requests, sessions, and business IDs
- Handling unknown results after disconnection
- Do not treat optional recovery capabilities as a strong guarantee