greatitself.
Continue
research28 min studyLesson 888 in Engineering

Cancellation: distinguish the request from quiescence and cleanup

Define nested deadlines, cooperative cancellation, child ownership, external-effect reconciliation, and bounded cleanup responsibilities.

Before you begin
On this page

The question for today

What you’ll understand

  • Calculate a child deadline bounded by its parent's remaining time.
  • Distinguish cancelled waiting from stopped remote work.
  • Assign durable ownership for cleanup and unresolved effects.

A timeout means the runtime stopped waiting under a policy; it does not necessarily mean the tool stopped executing. Cancellation is a request that must be delivered, handled, and reconciled with effects and cleanup. Define when a scope is considered settled, who owns remaining work, and what the user-facing terminal state promises.

Timeouts apply to specific intervals and owners

Separate queue wait, one attempt's execution, the total retry window, and the parent run deadline. Temporal documents distinct activity timeout types for these intervals. A shorter attempt timeout can trigger a retry while an old external request still runs, so the effect identity remains important. Use monotonic elapsed time for local deadlines and define how durable absolute deadlines are interpreted across workers. A timer firing is evidence that a limit was reached, not proof that the remote provider abandoned its operation.

A proposed child deadline should not exceed its parent's remaining authorized window. Reserve time and resources for cleanup or reconciliation when that is part of the contract. Distinguish a hard provider-enforced execution cap from an application timeout that only cancels a local await. An expired approval or budget can forbid a new attempt without undoing the previous one. The runtime needs a state for late receipts and unresolved effects rather than discarding them once its visible timeout message appears.

Dchild=min⁡(Dparent,tnow+τrequested)D_{\rm child}=\min(D_{\rm parent},t_{\rm now}+\tau_{\rm requested})
This proposed deadline rule uses one consistent time basis and nonnegative requested duration. Parent cleanup reserves or stricter provider/approval limits can shorten it further. It defines allowed waiting/dispatch policy, not a guarantee that remote execution stops exactly at D_child.↔ Scroll wide equations horizontally.

Cancellation is cooperative and may race completion

MCP 2025-06-18 defines cancellation notifications and receiver behavior, not a transaction rollback mechanism. A request may already have completed or reached an irreversible commit when cancellation arrives. Python task cancellation also has documented cooperative behavior; task groups wait for owned tasks to settle according to their semantics. A local coroutine's cancellation does not automatically kill a spawned process, background thread, or external server operation. Use the implementation's actual cancellation path and inspect its completion evidence.

Cleanup needs an owner and an idempotent protocol. Release only resources still owned by this scope under an appropriate lease, version, or effect receipt. A stale worker must not release a replacement worker's allocation. Some cleanup must run despite ordinary cancellation, but shielding everything can create unbounded hidden work. Use a narrow cleanup scope, a declared budget, and an escalation or durable handoff when settlement cannot complete. Preserve the unresolved obligation rather than falsely report that every effect was undone.

CancelRequested⁡⇏Quiescent⁡,CloseScope⁡⇒ChildrenSettledOrTransferred⁡∧ObligationsRecorded⁡\operatorname{CancelRequested}\not\Rightarrow\operatorname{Quiescent},\qquad \operatorname{CloseScope}\Rightarrow\operatorname{ChildrenSettledOrTransferred}\land\operatorname{ObligationsRecorded}
The second predicate is a proposed ownership rule: every child is settled or durably handed to a named owner, and unresolved effects/cleanup are recorded. It does not equate a transfer with completed external work or claim a protocol notification provides forced termination.↔ Scroll wide equations horizontally.

Test late outcomes and cleanup races explicitly

Inject cancellation before dispatch, during a tool call, after provider commit, and while compensation is running. Test a child that acknowledges slowly, ignores the request, or returns success concurrently with the parent deadline. Verify the accepted state transition and remaining obligations under every ordering. Record cancellation-request time, delivery evidence, tool completion, cleanup completion, and handoff identity separately. A cancelled response can be correct while reconciliation continues, provided the visible contract accurately states what remains.

The Markov lab offers only a conceptual pending-to-settled transition. Reset, set p=1 and q=0, predict state-one probability one after one Step, then Step once. Separately Reset, set p=0.50 and q=0, predict probability 0.75 after two Steps, then Step twice. It has no cancellation messages, workers, or cleanup. The incomplete mass in state one illustrates why a request and settlement are distinct concepts, but an exact probability curve cannot certify real child quiescence or resource release.

Work it through

A deadline can expire before cleanup finishes

A parent deadline is at second thirty. At second eighteen, a child requests twenty more seconds. The runtime uses the stated minimum deadline rule. Cancellation is requested at thirty, acknowledged at thirty-one, and owned cleanup finishes at thirty-four.

  1. The parent's remaining time is 30−18=12 seconds, so the child deadline is min(30,18+20)=30, not thirty-eight.

  2. At second thirty, cancellation is requested. The later acknowledgement at thirty-one does not itself prove cleanup is complete.

  3. Under this fictional observed timeline, cleanup finishes four seconds after the deadline and three after acknowledgement. Record those intervals and any unresolved remote effect rather than labeling second thirty an instantaneous stop.

The result

Waiting limits, cancellation acknowledgement, and settled cleanup occur at different times. A strict end-to-end bound would require an additional enforceable protocol.

The living notebook

Explore the model

Interactive lab

Interactive lab · markov

A requested transition is not proof of settlement

Reset, set p=1 and q=0, predict state-one probability 1 after one Step, then Step once. Separately Reset, set p=0.50 and q=0, predict 0.75 after two Steps, then Step twice. This exact two-state chain contains no cancellation notification, cleanup ownership, or remote operation.

A requested transition is not proof of settlementExact finite-step probabilities for a two-state chain starting in state 0, not sampled trajectories. Playback advances two transitions per second. When p = q = 0 every distribution is stationary; when p = q = 1 the chain alternates forever. A single zero transition creates an absorbing state. Current readings: P(state 1) at step 0: 0%; Stationary P(state 1): 60%; Chain behavior: Monotone convergence. All parameters are adjustable with the labeled controls below.Two-state Markov distribution after 0 steps: state zero probability 1, state one probability 0.Initial distribution (1, 0) · step 0p = 0.3q = 0.201100%0%1−p1−qP(0)P(1)Monotone convergence
P(state 0)P(state 1)Stationary distribution
P(state 1) at step 0
0%
Stationary P(state 1)
60%
Chain behavior
Monotone convergence
t = 0 s

Exact finite-step probabilities for a two-state chain starting in state 0, not sampled trajectories. Playback advances two transitions per second. When p = q = 0 every distribution is stationary; when p = q = 1 the chain alternates forever. A single zero transition creates an absorbing state. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forObserve or reconcile actual completion rather than inferring it from a cancellation request.

Pause & reason

Check your understanding

What should a runtime infer when its local tool wait times out?

Your turn

Try it yourself

A parent deadline is second fifty. At second forty-two, a child requests fifteen seconds. Under the stated minimum rule, find the child deadline and remaining interval. Does this force a remote process to stop there?

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Compare the requested endpoint fifty-seven with the parent's endpoint.

Compare with the solution

The deadline is min(50,42+15)=50, leaving eight seconds. This bounds the proposed local waiting/dispatch policy, not the remote process's physical execution. Forced stopping, cooperative acknowledgement, cleanup, and effect reconciliation need actual supported mechanisms.

Keep the idea

Take it with you

  • Queue, attempt, retry, and parent deadlines constrain different intervals.
  • Cancellation requests do not establish remote quiescence or rollback.
  • Cleanup and unresolved effects need explicit durable ownership.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.