A Go fan-in merge calls wg.Wait() and close(out) inline before returning out — why does it hang?

## The broken code ```go func mergeBroken[T any](srcs ...<-chan T) <-chan T { out := make(chan T) var wg sync.WaitGroup for _, src := range srcs { wg.Go(func() { for v := range src { out <- v } }) } wg.Wait() close(out) return out } ``` It reads as if it is being careful — wait for everyone, close cleanly, hand back a finished channel. It hangs the moment any source actually carries a value. ## Why it hangs An unbuffered channel send does not complete until a receive is executing on the other side; the two operations are a rendezvous. Here is the cycle: 1. A forwarder receives a quote from its source and executes `out <- v`. There is no receiver, so the goroutine parks. 2. Because it is parked, it never returns, so the `WaitGroup` entry for it is never released. 3. `wg.Wait()` in the merge function therefore never returns. 4. Because `mergeBroken` never returns, the caller never gets `out`, and so no receive is ever executed. Each party is waiting on the other. Note that `go vet` will not flag this and the compiler is perfectly happy: it is a legal program with a runtime dependency cycle. It will not even produce the friendly `all goroutines are asleep - deadlock!` panic in a real service, because that check only fires when **every** goroutine in the process is blocked. In a server with a listener and a metrics ticker still running, the merge just silently wedges the caller. ## Producer and consumer must overlap in time The underlying principle is broader than merging: with unbuffered channels you cannot sequence "produce everything, then consume everything" inside one goroutine. Producing and consuming are concurrent by construction. A function that both starts producers and waits for them must not be the same function that the consumer is waiting on. So the merge function's job is only to *set things up*: create the output, start one forwarder per source, start a closer, return. Everything that waits happens in a goroutine the caller is not blocked on. ```go go func() { wg.Wait() close(out) }() return out ``` ## Why buffering is not the fix Candidates often propose `make(chan T, 16)`. That changes when the deadlock happens, not whether it can. Sends complete without a receiver only while the buffer has room; the seventeenth value blocks and you are back in the same cycle. The buffered version is arguably worse, because it now deadlocks depending on how much data the sources happen to carry — a bug that appears in production and not in the small test. The only buffer that removes the hang is one at least as large as the total number of values that will ever flow, which for a live feed is unbounded. And even if you could size it, you would have destroyed backpressure: the merge would absorb everything into memory instead of letting a slow consumer slow the producers down. ## Why the test suite misses it Run `mergeBroken` over sources that are already closed and empty and it behaves perfectly: each forwarder's `range` ends immediately without ever sending, the counter drops to zero, `Wait` returns, `close(out)` runs, and the caller gets a closed empty channel. A unit test that merges two empty channels and asserts "no values, channel closed" goes green. The failure needs a value in flight, which is why it tends to be found by the engineer wiring up the first real feed rather than by CI. It is worth writing the test with actual values in every source and a bounded overall deadline, so that a hang is reported as a failure instead of a stuck run. ## The diagnosis in the moment If you are staring at a wedged process, a goroutine dump is decisive: you will see N goroutines parked in a channel send inside the forwarder, plus one goroutine parked in `sync.WaitGroup.Wait` in the merge function itself, and the caller blocked on the merge call. That triangle — senders waiting, a `Wait` waiting, and a caller waiting on the constructor — is the signature of this exact mistake, and it is worth being able to name on sight.