A running task instance is cancelled and removed from the process. Any work in progress is discarded. A cancellation signal from elsewhere in the process or externally terminates the specific task — other tasks in the process continue unaffected.
An AI report generation system accepts a user request and launches a long-running Report Generator agent (estimated 10 minutes for a comprehensive analysis). While the generator runs, the user navigates away from the page or clicks "Get Quick Summary Instead." A cancel signal is emitted. The Report Generator is terminated immediately — mid-execution, no partial output saved. The Cancel Handler activates the Quick Summary agent, which produces a 30-second summary. Both paths deliver to the same Deliver Output node.
The key insight: the cancel signal targets a specific task (Report Generator), not the entire process. The workflow instance continues — it routes through the Quick Summary path instead. Cancel Activity is surgical: one task stops, the rest of the process adapts and completes. This differs from Cancel Case (60.62), which terminates the entire process instance.
| Metric | Signal |
|---|---|
| Cancel signal latency | Time from cancel signal emission to task termination — primary responsiveness signal for the cancel path |
| Compute saved per cancellation | LLM tokens / GPU seconds avoided by cancellation — quantifies cost efficiency of the pattern |
| Cancel path output quality | User satisfaction rating for quick summary outputs — monitors whether the fallback path delivers acceptable value |
| Orphaned side effect rate | Fraction of cancellations that leave unresolved external state — monitors compensation coverage |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| Report Generator | Long-running agent that builds a comprehensive analysis report. Cancellable at any point. If cancelled, all in-progress work is discarded without producing output. | Report request + research scope | Full report (if completes normally) |
| Cancel Handler | Receives the cancel signal. Sends termination to the Report Generator. XOR split: routes to Quick Summary. Does not block — the process advances immediately. | Cancel signal from user or external trigger | Cancellation confirmation + Quick Summary activation |
| Quick Summary | Lightweight agent that produces a 30-second summary from available context. Runs only on the cancellation path. | Original request context | Brief summary (200..300 words) |
| Deliver Output | XOR join: receives either the full report (normal path) or the quick summary (cancel path). Delivers whichever output arrives. | Full report OR quick summary | Delivered output to user |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Future Cashflow | User experience on the cancel path | Delivering a quick summary immediately after cancellation retains user engagement. A cancelled request that returns nothing drives churn. |
| Conditional Action | Report Generator (cancelled) | Cancellation stops compute consumption immediately. A 10-minute agent cancelled at minute 3 saves 7 minutes of GPU/LLM cost — cost avoidance is proportional to cancellation timing. |
| Risk Exposure | Cancel Handler + Report Generator interface | If the Report Generator holds external locks or has written to side-effect stores before cancellation, a clean shutdown requires compensating actions. Cancellation without compensation leaves orphaned state. |
Cancellation is not failure. Cancel Activity is an intentional control-flow path, not an error handler. The Cancel Handler is a first-class workflow node, not a catch block. Treat the cancel path with the same rigor as the normal path — it must produce a valid, deliverable output.
The cancel signal is emitted at t=300s. The Report Generator completes at t=299s and writes its output to the Deliver Output node. Both the full report and the quick summary attempt to deliver. The XOR join must handle this race: whichever output arrives first wins, and the second is discarded. Fix: implement a first-writer-wins latch at the Deliver Output join; subsequent arrivals are silently dropped.
The Report Generator calls an external research API that has billable rate limits. The API call is in-flight when the cancel signal arrives. The agent is terminated, but the API call completes and is billed. Fix: the cancellation protocol must include a compensating call to the API to cancel the in-flight request, or the API budget must account for partial calls on the cancelled path.
The cancel signal is emitted but not delivered — the message queue drops it due to a transient failure. The Report Generator continues for the full 10 minutes. The user sees no feedback. Fix: cancel signals must be durable (persisted before delivery acknowledged); the Cancel Handler polls for acknowledgment and re-emits if not received within a timeout.
| Variant | Modification | When to use |
|---|---|---|
| Checkpoint-Preserving Cancel | Cancelled task saves its last checkpoint before terminating; fallback path resumes from checkpoint | Partial work from the cancelled task has value; the quick summary can incorporate what was completed before cancellation |
| Timeout-Triggered Cancel | Cancel signal is emitted automatically if the task exceeds a time budget | SLA enforcement — tasks that run too long should self-cancel and route to a faster fallback |
| Multi-Task Cancel | A single cancel signal targets multiple concurrent tasks | Several parallel agents are all running on the same user request; cancel should stop all of them simultaneously |
| Pattern | Relationship |
|---|---|
| 80.82 Cancel Case | Terminates the entire process instance rather than a single task — use when no continuation is possible or desired |
| 10.14 Retry-Fallback | Handles task failure rather than intentional cancellation — different trigger, similar alternative-path structure |
| 20.22 Human-in-the-Loop | Human approval gates can emit cancel signals; the cancel path is triggered by human decision rather than user interaction |