How should a Go producer avoid blocking forever when the bounded channel it feeds stays full?

## The problem with a plain blocking send A bounded intake channel is what gives a Go service backpressure: when the workers are behind, `events <- e` parks the producing goroutine. That is usually exactly what you want — the stall propagates upstream. But an unconditional park has no upper bound. If the consumers are deadlocked, wedged on a dependency, or simply gone, the producer waits forever. Its caller — an HTTP handler, an RPC method, a supervising loop — waits with it, holding whatever resources it holds, and the failure presents as a hang rather than as an error. So the pattern is: keep the blocking send as the normal path, and give it exits. ## The cancellation exit ```go select { case events <- e: return nil case <-ctx.Done(): return ctx.Err() } ``` `ctx.Done()` returns a channel that is closed when the `context.Context` is cancelled or its deadline passes. A closed channel is always ready to receive, so the moment the caller gives up, this `select` completes through the second case and the producer returns. `ctx.Err()` then tells the caller which happened — `context.Canceled` or `context.DeadlineExceeded`. This exit is the one to reach for first, because it costs nothing and it inherits the deadline someone upstream already set. If the request that produced this event has a two-second budget, the enqueue attempt should not outlive it. ## The deadline exit Sometimes the producer needs its own limit — a background reader with no request context, or a policy that says "we will wait 200 ms for room, then this event is not going in". ```go timer := time.NewTimer(200 * time.Millisecond) defer timer.Stop() select { case events <- e: return nil case <-ctx.Done(): return ctx.Err() case <-timer.C: return errQueueFull } ``` `time.NewTimer(d)` returns a `*time.Timer` whose `C` field delivers one value after `d`. `defer timer.Stop()` releases it as soon as the send wins rather than letting it run to completion. `time.After(d)` is the one-liner equivalent but allocates a fresh timer on every call and gives you no handle to stop, which matters in a hot loop. ## The branch people forget The give-up branch is where the design actually lives. Reaching it means an event exists that is not in the queue and never will be. Three defensible things to do with it, and one indefensible one: - **Return an error to the caller**, letting whoever produced the event decide — retry, buffer at their end, fail the request. This is the right default when the producer is a request handler, because the client learns the truth. - **Record it and move on**, incrementing an exported counter so the number of abandoned events is visible on a dashboard and can be alerted on. This is defensible for data whose owner has agreed it may be lost. - **Both** — count it and return a distinguishable error like `errQueueFull` so the metric and the caller agree. The indefensible one is a bare `return nil` in that branch. It converts a visible hang into invisible data loss, and nothing in the system will ever tell you it happened. ## What the bounded wait actually buys It does not increase throughput. Under sustained overload the queue is full most of the time, so a timeout on the send simply chooses *how long the producer is willing to participate in the stall* before giving up. What you gain is: - a bounded worst-case latency for the producer's caller; - an explicit, countable shed event rather than a silent pile-up; - liveness under consumer failure — a wedged worker pool degrades your service instead of freezing it. A short timeout sheds aggressively and protects latency; a long one preserves data and lets the stall keep reaching upstream. The number is a policy choice, and it belongs in configuration rather than baked into the call site. ## Details worth getting right If the channel has room *and* the context is already cancelled, both cases are ready and the choice between them is not specified — do not write code whose correctness depends on which one wins. Recreating a timer for every single event on a very hot path is measurable; reusing one `*time.Timer` with `Reset` is possible but easy to get wrong, and the usual answer is to make the timeout coarser or to attach it to a batch rather than to each item. Finally, a timeout on the send is not a substitute for bounding the channel. It is the escape hatch on top of a bound, not an alternative to one.