Why does a goroutine that sends its result on an unbuffered channel leak when the caller stops waiting?

## The shape This is the most common goroutine leak in real Go code, and it appears wherever work is started in the background and the caller has any way to give up: ```go func fetch(ctx context.Context) (string, error) { ch := make(chan string) // unbuffered go func() { ch <- slowWork() // blocks until someone receives }() select { case v := <-ch: return v, nil case <-ctx.Done(): return "", ctx.Err() // the goroutine above is now stranded } } ``` On the happy path this is correct: the `select` receives, the send completes, both goroutines move on. On the deadline path the caller returns. Nothing is left holding the receiving end. When `slowWork()` eventually finishes — a second later, a minute later — the goroutine reaches `ch <- ...` and parks. Forever. ## Why unbuffered means "forever" An unbuffered channel has no storage. A send is a **rendezvous**: the sending goroutine is parked on the channel's send queue until a receiver shows up, at which point the value is handed over directly and both continue. There is no "deliver it later", no drop, no error return. If no receiver ever arrives, the send never completes, and there is no timeout on a channel operation anywhere in Go. The leak rate is what makes this dangerous: it is *one goroutine per abandoned call*. A service that times out one request per second leaks 3,600 goroutines an hour, each holding the string, struct or buffer it computed, plus everything that value references. ## Fix 1: buffer for every value that can be sent ```go ch := make(chan string, 1) ``` One line. The worker's send now completes immediately into the buffer whether or not anyone is listening; the goroutine returns; the channel and its one value become garbage together once the caller drops its reference. The rule generalises: the buffer must have room for **every** value that could still be sent after the caller walks away. One goroutine sending one result needs capacity 1. Three racing workers each sending one result need capacity 3 — capacity 1 fixes the leak for the winner and leaves the other two parked. ## Fix 2: make the send abandonable ```go select { case ch <- v: case <-ctx.Done(): return } ``` A `select` with a send case and a cancellation case cannot park forever, because the cancellation channel is eventually closed and a receive from a closed channel is always ready. This is the right shape when the number of pending values is unbounded — a producer streaming into a pipeline — where you cannot size a buffer. ## What is not a fix - **Closing the channel from the caller.** A `close` unblocks blocked *receivers*; a goroutine blocked on a **send** to a channel that is then closed **panics** (`send on closed channel`). You have converted a leak into a crash. - **Setting a timeout on the send with `time.After` inside the worker.** It works, but it needs a timer per call and it duplicates a deadline the caller already has. Prefer the buffer. - **Assuming the runtime notices.** It does not: the rest of the service is runnable, so there is no deadlock to detect. ## Reviewing for it When you read `go func(){ ... ch <- x }()`, look at every path by which the receiving side can stop receiving. If any of them exists — a `select` with a second case, an early return, a `break` out of a loop, a caller with a deadline — then either the channel is buffered for the full number of outstanding sends, or the send is inside a `select` with an escape. Anything else leaks on that path, quietly, one goroutine at a time.