Two owners, one cancellation source: why async completion should come last

The reason this class of defect survives review is that nothing in it reads as wrong line by line. According to the dev.to write-up, the state on both sides of the gap is individually valid and only the ordering is wrong ^[7]. A reviewer who asks "is the snapshot correct" and "is the source disposed" gets yes twice, and the bug lives in the space between the two answers.

Count the exits. In the sequence described, the attempt publishes a settled snapshot to observers, completes a TaskCompletionSource, and only then clears the active task and disposes the cancellation source ^[5]. That is two independent ways to learn the operation is finished, both opened before ownership has moved anywhere: holding a published snapshot, and awaiting the task ^[1]. Both answer yes while the internal fields still say active ^[6]. In the generalized version, publication and TrySetResult both happen after a lock-protected block that nulls the active attempt and disposes the source ^[12], which takes the number of completion signals available before handoff from two to zero ^[1].

The mechanism worth taking is smaller than the slogan around it. The author's point is that neither Cancel nor Dispose is the load-bearing operation: it is reading the shared field and clearing it while holding the state lock, so the local variable becomes sole owner and any other path entering that lock finds null and knows it owns nothing ^[9]. Cancel and Dispose then run outside the lock, keeping callbacks and slow work away from protected state ^[10]. He is explicit that this is not an instruction to dispose everything inside a lock; only the transition has to be atomic, and what follows depends on whether disposal can block, invoke callbacks, or acquire other locks ^[13].

The suggested regression test only works if the ordering is already right. Block inside the observer that receives the settled snapshot, then inspect the object from another thread while publication is paused ^[15], checking that the previous attempt is no longer active, that a new start cannot pick up the stale completed task, that disposal does not compete for the same source, and that repeated disposal stays harmless ^[16]. Under the old order the observer is running inside the window, so those assertions have nothing solid to stand on. Fix the sequence and the same hook becomes a boundary test rather than a coin flip.

What the discipline buys is a lifecycle contract that can be recited: one owner at a point in time, observable completion implying released attempt state, idempotent disposal, and an immediate retry that starts new work ^[19]. Provenance is worth keeping in view. This is one engineer's inspection of one committed change, which applied singular cancellation-source ownership across two similar async workflows ^[20][2], not a survey of how often the window actually opens in production.