A Go multiplexer nils each select case as its stream ends, then dies with a fatal all-goroutines-are-asleep deadlock. What went wrong?

## What the code does A stream demultiplexer reads length-prefixed frames off one connection and fans them into per-stream channels, with a `select` loop that watches several of them at once. As each peer finishes, its channel is closed, the loop's comma-ok receive reports `ok == false`, and the loop sets that channel variable to nil to retire the case — the standard idiom, and correct as far as it goes. The bug is in the surrounding loop, written as `for { select { ... } }`. Disabling a case does not remove it and does not end the statement. When the last variable becomes nil, the `select` is left with cases that can never be ready and no `default`, so it blocks. A `select` in that state is not an error; it is simply a wait for an event that cannot occur. The goroutine parks and no code path exists to wake it. ## Why it becomes a fatal error rather than a hang The Go runtime aborts the process when it can see that no goroutine will ever run again — every goroutine is parked on a channel or a synchronisation primitive with nothing left to signal it. The report is `fatal error: all goroutines are asleep - deadlock!`, followed by a dump of every goroutine and its wait reason. That is why a targeted unit test on the multiplexer crashes loudly. In the full service, other goroutines are alive and doing work, so the same defect shows up as one wedged stream and a goroutine that never returns — quieter, and usually noticed later. Recognising that the crash and the wedge are the same bug is the main thing this scenario tests. ## Reading the dump when none of the frames look familiar The dump lists each goroutine with a bracketed wait reason, and the reasons are specific enough to steer you: ```text goroutine 1 [select]: main.pump(...) goroutine 8 [chan send]: goroutine 9 [chan receive (nil chan)]: ``` - `[select]` on a goroutine whose top frame is your loop is the signature of this bug: the statement is live, but nothing it waits on can fire. - `[chan receive (nil chan)]` or `[chan send (nil chan)]` names a bare operation on a nil channel outside a `select` — usually a channel that was never given to `make`. - `[chan send]` on peers is a consequence, not a cause: they are blocked writing into a demultiplexer that has stopped draining. The practical technique when the dump is long and none of the top frames are yours is to sort by wait reason rather than reading top to bottom. Goroutines parked on `chan send` are almost always victims; look for the single goroutine parked in `select` or on a nil channel and start there. It is also worth remembering that this report is a fatal runtime throw, not a panic, so no deferred function runs and no `recover` intercepts it — you get the dump and the process exits. ## The fix Make termination the loop's responsibility, so that the condition mirrors the disabling: ```go for ctrl != nil || data != nil { select { ... } } ``` With a variable number of streams held in a map or slice rather than in named variables, keep an integer count of live sources, decrement it where you would have nil'd, and return when it hits zero. If the loop must outlive its inputs — a multiplexer that expects new streams to be registered later — then it needs a case that is *always* live, such as a registration channel or a cancellation signal, so the select is never left with only disabled cases. ## How to keep it from coming back - Treat "every case disabled" as a state the loop must handle explicitly, the same way you would handle an empty work set anywhere else. - Give the loop a test that drains every source and asserts the function returns. That is the test that turns this bug into a red build instead of a production wedge, because in a small test the runtime's deadlock report fires immediately. - Prefer a bounded shape over a hand-rolled one when the source count is dynamic: a counter plus a return is easier to review than a chain of nil comparisons. - When you review a `select` inside a bare `for {}`, check straight away whether any case can be disabled at runtime. If one can, the loop is missing an exit. ## The summary answer The idiom is right and the loop is wrong. Disabling cases with nil is how you retire finished sources; deciding that there is nothing left to wait for is a job the `select` cannot do for you, and if you leave it to the `select`, the best case is a fatal error in a test and the worst case is a silently stuck goroutine in production.