Stop distributed work through its task hierarchy and distinguish a stop request from the durable outcome.
A request can leave work running on several machines. Cancellation follows the connected tasks so stopping the parent can reach delegated work as well.
Deadlines put a time boundary on execution. The outcome still matters: a request to stop and a confirmed stop are different events.
Distributed task trees explains the hierarchy and attribution. Observability shows what happened along it.
Developer reference
Task context carries cancellation and deadline information across execution boundaries. Descendants observe that context rather than treating a disconnected browser or completed HTTP request as the lifetime of the whole operation.
A cancellation signal needs to reach the executing task and be observed at a supported interruption point. Network partitions and irreversible operations prevent an instantaneous global stop guarantee.
Concurrent cancellation and finalization must resolve to one outcome. The task registry coordinates who owns cancellation and whether execution has crossed an irreversible boundary. A deadline supplies a distinct termination cause, so callers can distinguish expiry from an explicit cancellation request.
A task tree can contain many workspace transactions. Cancellation cannot roll back an already committed transaction or undo an external side effect merely because its parent stopped. Inspect the recorded outcomes and transaction-linked audit trail to distinguish committed work from unfinished descendants.
Execution deadlines are not a promise of complete token-budget enforcement, automatic refunds, or cross-workspace atomic rollback.