If a Go pipeline's consumer stops receiving halfway, what happens to the upstream stage goroutines?

## What "abandoned" means A pipeline is built so that values are pulled through it: each stage can only make progress when the stage after it receives. The consumer at the end is what keeps that motion going. When the consumer stops early — a `break` on the first corrupt frame, an HTTP handler whose request was cancelled, a `return` on an error — the pull stops, and everything upstream stalls at the point where it was pushing. Concretely, with three stages over an unbuffered chain: 1. the encode stage evaluates `out <- v` and parks, because nobody is receiving; 2. the resize stage finishes its next frame, evaluates its own send, and parks; 3. the decode stage does the same one item later. All three goroutines are now blocked forever. Nothing has failed: a send with no receiver is not an error in Go, it is simply a wait. ## Why the runtime cannot clean this up A goroutine blocked on a channel operation is a root for the garbage collector, not garbage. The runtime has no way to prove that no future receive will arrive — the channel might still be referenced by code that has not run yet — so the goroutine, its stack, and every value reachable from it stay live. In a photo pipeline that means the decoded pixel buffers in flight are pinned too, so the leak is measured in megabytes, not just in goroutine count. Also worth stating clearly, because it is a common wrong guess: goroutines have no parent-child relationship. Returning from the function that started a stage does nothing to that stage. The runtime's deadlock detector will not help either — it only fires when **every** goroutine is asleep, and a real service always has others running. ## The fix: a cancellation signal every stage watches The stage takes a `context.Context` as its first parameter and selects its send against cancellation: ```go select { case out <- v: case <-ctx.Done(): return } ``` `ctx.Done()` is a channel that is closed when the context is cancelled, so every stage watching it is released at once — closing is a broadcast. On the return branch, the stage's `defer close(out)` fires, which also terminates the range loop of whatever is downstream, so the chain unwinds cleanly from any point. The caller owns the signal: ```go ctx, cancel := context.WithCancel(context.Background()) defer cancel() ``` The `defer cancel()` is not optional bookkeeping — it is the entire mechanism. A pipeline wired with a context whose `cancel` is never called leaks exactly as badly as one with no context at all, and so does a stage that accepts a `ctx` but never selects on `ctx.Done()` at the send. A `done chan struct{}` closed by the caller works identically and predates `context` in this pattern; use a context when the pipeline sits under a request or under some other cancellable operation, which is usually. ## Where to watch, and where not to bother The **send** always needs the select, because that is where a stage parks when its consumer is gone. The **receive** needs it only when the stage's input might never be closed — a generator reading from a network connection or a long-lived queue, say. When the input is another stage that always closes its output, `for range in` terminates on its own as soon as the upstream stage exits. A note on capacity: giving the channel between two stages a buffer does not fix this. It lets the producer run ahead by the buffer's capacity, then the send parks exactly as before. The block moves a few items later; the goroutine still never returns. ## Seeing it and proving it In a running process, the goroutine profile is the direct evidence: it dumps every live goroutine with its state and stack, so a leak shows as a growing population of goroutines sitting in `chan send` at one particular stage's line. A CPU profile shows nothing at all, because blocked goroutines burn no CPU, and the race detector shows nothing either — a goroutine politely blocked on a send is not a data race. The test worth writing is an abandonment test: build the chain, consume two frames, cancel, and then assert that every stage actually returned — wait for each stage's output channel to be closed and drained, with a timeout, so a stage that never exits fails the test deterministically. That is far better than sleeping and sampling a goroutine count, which is timing-dependent and flaky.