A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. On cancel, stop scheduling locally immediately rather than waiting for a round trip. Remote cancel is idempotent and races completion in one state machine.
A product loop covers start, wait, cancel, failure, recovery, and re-entry while automation obeys the user’s latest explicit choice. Metrics measure task outcomes rather than button clicks.
Questions the design must answer
Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.
- Move UI immediately to cancelling/cancelled, prioritize cancel on control, surface unknown remote state after timeout, and let users choose whether resume data remains.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for Cancellation: Immediate UI, Remote Convergence, and Residue is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.
- Cancel behind bulk data arrives too late, while deleting receiver data unconditionally destroys expected later resume.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- Without backpressure or quota, a slow consumer raises memory, queue depth, and tail latency until unrelated users are affected.
Prove that it works with evidence
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- At every stage race cancel on both peers, completion, and disconnect; measure local response, remote convergence, resources, resume policy, and duplicate idempotency.
- Disconnect, change networks, and recover mid-operation; reconcile endpoint state, persistence, and resource counts.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
Completion is not one passing path. Every terminal state reconciles, automation stays below user intent, and every operational cost has an explicit ceiling.