A message subscription stops delivering values — how can the code tell a cancelled run from a completed one, and why does the difference matter?

## Two endings that look alike and are not From outside, both endings look identical: values stop arriving. Inside the subscription they are opposites. - **Completion** is a **terminal signal** produced by the source and delivered downstream. It means *there is nothing more to produce, and nothing went wrong*. It arrives exactly once and ends the sequence for the subscriber. - **Cancellation** is a **request** produced by the subscriber and delivered upstream. It means *I no longer want values*. The subscriber is not owed a signal in return; it stops hearing because it asked to. So the honest answer to "how can the code tell" is: **by which path fired, not by observing the silence.** Silence is common to both, and to a source that is simply slow. | | Completed | Cancelled | |---|---|---| | Who initiated it | The source | The subscriber | | Direction | Downstream signal | Upstream request | | Completion handler runs | Yes | No | | Any-ending teardown hook runs | Yes | Yes | | Meaning | The work finished | The work was abandoned | ## Why the distinction has teeth An ending is usually the moment code commits something, and committing the wrong thing is a correctness bug, not a cosmetic one. - **Treating a cancel as success.** The conversation is marked fully synchronised, a batch is committed as delivered, a cursor is advanced past messages that were never handled. The user closed the screen mid-stream and the system recorded that everything arrived. - **Treating a cancel as failure.** The other error: a retry fires, or a failure path runs, for a run that nobody wanted any more. At best it wastes the work again; at worst it re-opens the resource the cancel was supposed to release. - **Treating a cancel as still running.** Code that waits on the subscription for a terminal signal that will never come waits forever. The correct default is that **cancellation is neither success nor failure** — it is abandonment, and most decisions that hang off an ending should simply not be taken. ## How to make it knowable Since the contract gives the subscriber no cancellation signal, the code must record the fact where it is known: 1. **At the cancel site.** The owner that cancels knows it did; it can set the reason before cancelling, so the any-ending hook reads it rather than guessing. 2. **In the hook's parameter.** Where the mechanism offers an ending reason to the any-ending hook, use it, and branch only where the decision genuinely depends on the ending. 3. **By keeping commits out of teardown.** A commit placed on the completion path alone is automatically correct: it cannot fire on a cancel, because the completion handler never runs for a cancelled run. The third is the cheapest and most reliable. Put release logic in the any-ending hook and meaning-bearing logic on the specific ending that licenses it. ## The trap in review The defect shape is specific and easy to spot once you know it: a single block of code doing both release and commit, attached to whatever hook fires on every ending. It reads like tidy cleanup, it passes tests (which always let the sequence complete), and in production it marks abandoned work as finished every time a user closes a screen. Splitting that block — release unconditionally, commit only on completion — is usually a two-line change and removes the whole class. Stated for an interview: completion is a signal you receive, cancellation is a request you sent; only the first tells you the work is done, so never let a hook that fires on both decide that it was.