Why do a Go fan-in merge's forwarding goroutines leak when the consumer abandons the merged channel?

## The scenario A market-data service merges quote streams from several providers into one channel and a single consumer loop reads it. One day the consumer stops early — a downstream write fails, a deadline elapses, or someone adds a `break` when a bad quote arrives — and returns without draining the merged channel. Nothing crashes. Nothing logs. The service keeps serving. But the goroutine count starts climbing, and a week later the process is holding gigabytes of goroutine stacks and blocked feeds. ## Why a blocked forwarder is permanent The forwarder body is `for v := range src { out <- v }`. That send is a rendezvous: it completes only when a receive executes on `out`. Once the consumer is gone there will never be another receive, so the goroutine is parked in a channel send with no possible wakeup. Three consequences follow, and the second is the one interviewers listen for: 1. **The goroutine is never collected.** Go's garbage collector reclaims unreachable *memory*; it has no notion of an unreachable goroutine. A goroutine blocked forever is a live goroutine forever, and it is itself a GC root — its stack keeps the value in flight, the source channel and anything those reference alive. 2. **Blocking propagates upstream.** The provider goroutine feeding that source now has no reader either, so it parks on its own send in turn. One abandoned consumer can stall an entire chain. 3. **The merged channel is never closed.** The forwarders never return, so the `WaitGroup` counter never reaches zero and the closer goroutine sits in `Wait` forever. That is a seventh leaked goroutine on a five-source merge, and it also means any other code waiting for the merged channel to close waits forever. ## Diagnosing it The symptom is a monotonically rising goroutine count that never falls back after load subsides. `runtime.NumGoroutine()` exported as a gauge is enough to see it; a step of exactly *sources + 1* per incident is a strong hint that a merge is the culprit. Compare that count against the number of live provider connections — if goroutines grow while the feed count stays flat, something per-merge is not exiting. The goroutine profile then names it precisely, because it groups goroutines by identical stack and shows the blocking state: ``` goroutine 217 [chan send]: main.merge[...].func1() /app/feed/merge.go:14 +0x8c ``` A large count of goroutines in the `chan send` state, all at the same line inside the merge, is the whole diagnosis. This is not something the race detector will show you: nothing here is a data race, it is a liveness bug, and `-race` reports neither. ## The fix: make the send abandonable A forwarder must be able to give up, which means the send must appear in a `select` alongside a cancellation signal: ```go for v := range src { select { case out <- v: case <-ctx.Done(): return } } ``` The merge takes a `context.Context` as its first parameter, and the consumer owns cancelling it — `ctx, cancel := context.WithCancel(parent)` followed by `defer cancel()`, so that every exit path from the consumer, including a panic unwinding through it, releases the merge. When `cancel` runs, `ctx.Done()` closes, every parked forwarder wakes on that case and returns, the `WaitGroup` drains, and the closer goroutine closes the merged channel and exits. The whole merge unwinds within one scheduling round. Note what this does **not** promise: the value the forwarder was carrying is dropped, so if losing an in-flight quote matters you need acknowledgement at a higher level. Cancellation is abandonment, and that has to be an explicit product decision, not an accident. ## The alternative fix, and its limit Instead of cancelling you can *always drain*: `go func() { for range merged {} }()` on the abandonment path. Every forwarder eventually completes its send, its source runs dry, and the merge closes itself. This is only correct if every source is guaranteed to close on its own. For a live feed that never ends it just moves the leak — now the drainer goroutine runs forever. Draining is right for a bounded batch; cancellation is right for a stream. ## Making it a habit The rule worth stating in review is: **any goroutine that sends into a channel it does not own must have a way to stop that does not depend on the receiver.** In practice that is a `ctx.Done()` case on every send in a forwarder, a `defer cancel()` at every consumer, and a documented statement on the merge's exported signature about who cancels. Once the merge takes a `Context` as its first parameter, the obligation is visible at every call site instead of living in a comment.