Crypto workflow cancellation propagation should stop downstream scheduling, request cancellation of running branches, and reconcile any external effects already attempted. A run is not safely settled merely because its parent task stopped. Keep cleanup and order-status recovery available until every branch has a known outcome or an explicitly owned unresolved state.
A trader may cancel because an approval expired, an input became unreliable, or an operator intervened. The difficult interval begins after that decision: some work has not started, some is running, and one request may already have crossed the exchange boundary. Those cases need different handling.
This article presents an educational reference design, not a description or guarantee of KLINEO's cancellation implementation. The trading-bot kill-switch guide covers control scope. Here the narrower question is how one canceled run stops producing work while preserving evidence of what it already did.
Make cancellation a durable run state
Record a cancellation request against the run identity, with its reason, scope and time. A useful design distinguishes cancellation requested, draining, and settled. These are proposed lifecycle labels, not universal engine statuses.
Cancellation requested means the run has lost permission to advance its original plan. Draining means its remaining branches are stopping or reporting their outcomes. Settled means local work is accounted for and external obligations are resolved under the chosen policy. If an order remains ambiguous, retain an unresolved state and a named recovery owner rather than claim complete settlement.
The transition must survive a worker restart. An in-memory flag can disappear while durable queued messages remain. Workers should consult the current run state when claiming work and before scheduling a successor. Delayed messages need the same run identity so they cannot revive an old decision after recovery.
A research-tool circuit breaker answers whether a failing dependency should receive calls. Cancellation answers whether this particular run may continue. A healthy tool can still belong to a canceled run, and reopening a circuit does not restore that run's permission.
Close scheduling before waiting for branches
Stop admission of ordinary downstream work first. Otherwise a branch can finish during shutdown and enqueue a new analysis, approval or execution step while the coordinator waits for its siblings.
Include pending retries, delayed jobs, join callbacks and approval responses in that rule. A response that arrives after cancellation may still be valuable evidence, but it must not become fresh permission to execute. Preserve its result with a late-arrival reason and prevent its normal successor.
A worker can also pass a cancellation check just before another process records the stop. Coordinate the cancellation decision with the final submission-admission boundary. A last-second local check alone cannot retract a request already sent over the network. Where the ordering is uncertain, record the attempt and reconcile it.
Workflow concurrency limits restrict how much work can run. They complement this rule but do not establish that a canceled run cannot start another task. A newly free worker slot must still reject canceled work.
Drain branches without erasing cleanup
Send the engine's supported cancellation signal to running child tasks, then track their completion. Some tasks cooperate promptly; others finish before they observe the signal. Detached remote jobs require their own supported stop mechanism or continued observation.
Python's asyncio task-cancellation documentation illustrates cooperative behavior: cancellation raises an exception at the next opportunity. It recommends cleanup in try/finally and generally propagating the cancellation exception after cleanup. Catching it and returning a normal successful result can interfere with structured cancellation.
Keep a bounded cleanup path available to persist outcomes, release eligible local resources and arrange reconciliation. Do not let a generic canceled-run filter discard those recovery messages. Conversely, cleanup permission should not become permission to resume the original entry plan. Separate allowed recovery operations from ordinary branch continuation.
This distinction also exists outside a single process. AWS documents that when a Step Functions Parallel state fails, invoked Lambda functions can continue running and activity workers are not automatically stopped. That is an AWS-specific example of why parent termination cannot establish child termination in every engine.
A run that stops with four ABC already bought
Consider a hypothetical spot workflow proposing a limit purchase of 10 ABC at 20 USDT per ABC. It records a maximum gross notional commitment of 200 USDT before attempting submission. Assume no prior ABC, no other account activity, fills only at 20 USDT, and no fees for this arithmetic. The names, times and reservation policy are constructed examples.
At cancellation, the branch ledger looks like this:
| Work item | State when stop is recorded | Required handling |
|---|---|---|
| Optional research summary | Queued, never claimed | Mark skipped by cancellation; prevent retry |
| Market-quality calculation | Running locally | Request cancellation; retain any late result without advancing |
| Entry submission | Request already sent; reply missing | Preserve order identity and recover the exchange outcome |
| Final decision join | Waiting for branches | Close ordinary continuation; keep recovery tracking active |
Suppose cancellation is recorded at 115 milliseconds after the entry attempt. A later lookup finds that the order is active with three ABC filled. The recovery policy requests cancellation of the remainder. By the time the exchange confirms the terminal state, cumulative fills have reached four ABC.
| Reconciled item | Calculation | Result |
|---|---|---|
| Original gross commitment | 10 × 20 | 200 USDT |
| Acquired inventory | Final cumulative fills | 4 ABC |
| Gross purchase cost | 4 × 20 | 80 USDT |
| Unfilled quantity canceled | 10 − 4 | 6 ABC |
| Unused gross commitment | 6 × 20 | 120 USDT |
Under this example's reservation policy, the 120 USDT can be released after the canceled remainder is confirmed. The 80 USDT became acquired inventory; it did not become unused budget. Actual fees and other reservations require separate accounting, so these figures are not a live available-balance calculation.
The local task cancellation did not undo the purchase. Selling the four ABC would be a new trading action with its own authorization, price and execution risks. Existing protective orders also need their own review; blindly canceling all descendants could remove protection while leaving inventory intact.
Preserve the uncertain external boundary
For every attempted write, retain the intent identity, account, environment, instrument, request time and any exchange order ID. A canceled HTTP wait establishes that the caller stopped waiting, not that the exchange rejected the request.
Binance Spot's general REST API information explicitly treats its processing timeout as an unknown execution result and directs clients to query status if no result appears in the user data stream. That venue-specific rule supports recovery before another submission; it does not establish behavior for every exchange or transport error.
The order-timeout reconciliation guide covers the lookup and fill ledger in detail. Here the cancellation requirement is to keep that recovery reachable even after ordinary branches have stopped. The idempotency guide explains why a retry must remain linked to the original intent.
Set a drain deadline, but treat expiry as escalation rather than proof that remote effects vanished. Retain unresolved attempts and their capacity commitments until the relevant policy can resolve them. A process crash during cleanup should leave enough durable evidence for another worker or operator to take ownership.
Test the stop boundary, not just the button
Use a supported simulation environment or a tabletop exercise before relying on the design. Check the workflow activation guide for current KLINEO testing boundaries; an available Live activation control is not permission to conduct an emergency drill with real funds.
| Injected condition | Evidence the exercise should produce |
|---|---|
| Cancel before a queued task is claimed | Task skipped; zero ordinary successors |
| Cancel while a result is arriving | Result retained; join cannot authorize execution |
| Cancel after the order request is sent | Original intent enters reconciliation; no duplicate entry |
| Worker restarts while draining | Cancellation state and unresolved attempts survive |
| Child ignores cancellation | Visible deadline breach and recovery owner |
| Cleanup query fails | Uncertainty retained; no false settled status |
A cancellation receipt should identify the stopped run, each branch's disposition, outstanding external effects and who owns any remaining uncertainty. Resume should create a deliberately reassessed decision with current inputs and permissions. It should not silently replay the canceled run's queued work.
Editorial method: prepared with AI assistance from the primary documentation cited above. The lifecycle, ledger and test worksheet are original educational examples, not a customer incident or live cancellation test. Report a correction.