In a Go for-select loop, what do you check before approving a pull request that adds a new case?

## Why adding a case is not a local change A for-select loop is the single-threaded heart of a component. Every case shares one goroutine, one stack and one set of local state, and that is the whole reason the pattern is safe without a mutex. Adding a case adds a new claim on that one goroutine, so its effects are global to the loop even though the diff is four lines. Here is what I read for, roughly in the order I find problems. ## 1. Does the body block? While a case body runs, the goroutine is not in the select. Nothing else is being served: keystrokes queue, resize events queue, and the cancellation case is not even looked at. A body that does a synchronous write, a network call, or a lock acquisition with contention converts the loop's latency for every source into that body's duration. The fix is not to make the loop concurrent — that reintroduces the races the loop was avoiding. It is to move the slow work out: hand the value to a dedicated worker goroutine over a channel and return to the select immediately. If the handover itself can block, that is the next thing to look at, because a blocking send inside a case body is the same bug wearing a different hat. ## 2. What is the exit path? Every case body must end in one of two ways: fall out of the select and go round the loop, or `return`. A new case that returns must do everything the existing return paths do — the same deferred cleanup, the same signal to whoever is waiting for this goroutine to finish. A new case that can neither return nor complete quickly extends how long the component takes to stop, which is often what a reviewer notices last and an on-call engineer notices first. ## 3. The arithmetic of the choice Among cases that can proceed, Go chooses uniformly at random. That means the probability of any particular case being chosen is one over the number of *currently ready* cases. A loop with two work cases and a cancellation case picks cancellation a third of the time when everything is busy; add a fourth and it is a quarter. The expected number of extra work items handled after cancellation goes up correspondingly. So a pull request that adds a case has, as a side effect, changed the shutdown behaviour of the component without touching the shutdown code. If the component has a stated stop budget, this is where it quietly gets spent. ## 4. Where does the channel come from, and does it close? Ask who sends on it and whether anyone closes it. A receive case on a **closed** channel succeeds immediately on every pass, forever — so a case whose channel gets closed while the loop still selects on it turns the loop into a spin that consumes a core and drowns out the useful cases. If the closure is meant to signal something, the case body must act on it and leave the loop rather than continue. If the new case is a **send** rather than a receive, the question inverts: is a receiver guaranteed to be there? A send case that can never proceed is merely never chosen, which is quiet — the value is computed and discarded on every pass and nobody notices until you look at why the loop is allocating. ## 5. What is in the case header? Case expressions are evaluated on every entry to the select, before any case is chosen. A call in the header runs every pass whether or not its case wins, and a call that changes state there drops work invisibly. A case header should name a channel and, for a send, a value that already exists. ## 6. How would we know if this is wrong in production? I want the loop to be observable before it grows. A counter per case, exported, answers most questions after the fact: a case that never increments is a channel nobody feeds; one that dominates is starving the rest by holding the goroutine. For a live investigation, a short recording with `go tool trace` shows the goroutine's timeline — how much time it spent parked in the select versus running in a case body, and which stretches of wall-clock the loop was unavailable. That evidence distinguishes "the select kept choosing the other case" from "one case body ran for 400 ms", which need completely different fixes. ## The summary I give the author If the case is a fast, non-blocking handler for an event that genuinely belongs to this component's state, add it. If it blocks, if it needs its own error handling, or if it is really a second responsibility, it wants its own goroutine and its own loop — and then the two loops communicate over a channel, which is a change the reviewer can reason about locally.