Task Deadlines & Cancellation
What happens when a task runs out of time?
Reference notes by Min · Reviewed October 15, 2026
Definition
A task deadline bounds how long a workflow may continue. A timeout limits how long one component waits. Cancellation requests that work stop, but its actual effect depends on which downstream operations can still be interrupted.
A workflow can contain several kinds of time. The user may have a completion deadline, a tool may have a network timeout and an approval may expire independently. Make each condition explicit so a slow operation does not silently extend the authority under which it runs.
What it covers
- Deadline
- The task’s remaining time budget.
- Timeout
- A wait limit for one call.
- Cancellation
- A signal to stop preventable work.
- Outcome
- Completed, stopped, failed or uncertain effects.
Identify the commitment point of each consequential operation. Before that point, cancellation may prevent the change. After it, the appropriate response may be reconciliation or compensation. A local cancellation acknowledgment says little about an external service unless the contract defines it.
In practice
Practical design patterns by Min.
- Carry the remaining deadline into child work.
- Stop scheduling new actions when the task ends.
- Reconcile consequential calls whose outcomes are unknown.
Record task state transitions and stop accepting new child work after termination. Use remaining time rather than a fresh fixed timeout at every layer. Define who owns uncertain outcomes and how the user can discover a later completion.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Timeout does not settle the outcome
Amazon’s guidance discusses timeout selection and the risks of retries when operations have side effects. The cancellation state model here is an agent-specific application.
Source: Amazon Builders’ Library: Timeouts, retries, and backoff with jitter ↗
Working example
An invoice submission times out
The agent stops waiting after sending an invoice to an external system.
- Record the outcome as uncertain rather than unsubmitted.
- Query status using the transaction reference.
- Retry only through an appropriate duplicate-safe path if the task remains authorized.
Why the controls matter
The invoice may already exist even though the response was lost. Resubmitting blindly can create duplicates. A stable operation reference allows the next handler to inspect the service state and report a precise outcome instead of guessing from the timeout.
Common pitfalls
- Assuming closing the chat cancels every job.
- Giving every retry a new full task budget.
- Reporting cancellation as proof that no external action occurred.
Very short timeouts can increase failure and retry load; very long ones can retain resources and delay intervention. Choose them using observed service behavior and business consequence, then test delayed responses and cancellation races.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Where is the task deadline enforced?
- Which accepted operations cannot be cancelled?
- Who resolves a result that arrives after the user stopped waiting?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- Amazon Builders’ Library: Timeouts, retries, and backoff with jitter ↗Accessed October 15, 2026
- IETF RFC 9110: HTTP Semantics, conditional requests ↗Accessed October 15, 2026