Pipelines and Stages

## The shape of a stage A Go pipeline is a chain of functions that all share one signature: ```go func stage(in <-chan In) <-chan Out ``` Each stage takes a receive-only input channel, creates its own output channel with `make`, launches exactly one goroutine to do the work, and returns the output channel **immediately** — before any value has been produced. The caller wires the chain by feeding one stage's return value into the next: `encode(resize(decode(paths)))`. Three stages means three live goroutines, each parked at its send or its receive until a neighbour is ready. Three properties fall out of that shape, and they are what an interviewer is checking. ## 1. One channel, one creator, one closer A stage calls `make` exactly once, for its output. That is the only channel it sends on, and the only one it closes. The input belongs to the stage upstream; this stage only receives from it. The rule is not aesthetic — the runtime enforces it with panics: - a send on a closed channel panics with `send on closed channel`; - closing an already-closed channel panics with `close of closed channel`; - closing a nil channel panics. A receiving goroutine has no way to know whether some sender is mid-send, so a receiver can never close safely. A sender always can: it knows when it has sent its last value. Hence "the sender closes". ## 2. close is a broadcast, not a cleanup Closing a channel signals receivers that no more values are coming. Every receive on a closed and drained channel returns immediately with the element type's zero value and `ok == false`, and a `for v := range ch` loop terminates. That is the **only** way a range over a channel ends: not when the channel happens to be empty (an empty open channel blocks the receiver), not on a zero value, and not when the sending goroutine simply returns without closing — that leaves the downstream loop blocked forever. Closing is also not a resource release. A channel is an ordinary heap object; once nothing references it, the collector reclaims it whether or not it was closed. You close a pipeline channel so the downstream `range` terminates, not to free memory. The mirror image is worth knowing too: a channel still referenced by a goroutine blocked on it is never collected, and no amount of closing elsewhere fixes that. ## 3. Shutdown cascades Because every stage closes its own output once its input runs dry, closing the head closes the whole chain: generator's `defer close(out)` → resize's `range` ends → resize's `defer close(out)` → encode's `range` ends → encode's `defer close(out)` → the consumer's `range` ends. Write the close as `defer close(out)` at the **top** of the goroutine rather than as a statement after the loop. Deferred there, it also runs on an early `return` — a cancellation branch, say — and on a recovered panic, so the downstream loop always terminates no matter how this stage exits. ## The type is the enforcement Return `<-chan Out`, not `chan Out`. Direction is part of a channel's type, and `close` and send are simply not operations on a receive-only channel: `close(c)` where `c` is `<-chan Frame` fails to compile. Likewise the parameter is `in <-chan In`, so no stage can close its input by accident and no stage can inject values into another stage's channel. That one typing decision turns the ownership convention from something a reviewer must remember into something the compiler checks. It is why you will see this exact signature in every idiomatic Go pipeline. ## The two mistakes - **Closing the input to be tidy.** It panics the stage upstream, which is still sending — and the stack trace names that upstream stage, not the closer. - **Never closing the output.** The downstream `range` never returns, so the pipeline hangs at the consumer with no panic and no error at all.