Do you still need to drain a time.Timer's channel before calling Reset, and what breaks if you do?

## The problem the drain idiom solved Up to Go 1.22, the channel inside a `time.Timer` or `time.Ticker` had capacity one. When the timer fired, the runtime performed a non-blocking send: if a receiver was waiting, it got the value; if not, the value sat in the buffer until someone took it. That buffer is what made re-arming a timer subtle. Consider a loop that arms an idle deadline each pass. If the other `select` case wins, the timer may nevertheless have fired a microsecond later and parked a `time.Time` in the buffer. Call `Reset` and the very next receive on `t.C` returns immediately with that stale value, and your deadline appears to expire instantly. Hence the protocol everyone copied: ```go if !t.Stop() { <-t.C } t.Reset(interval) ``` `Stop` returns `false` when the timer had already fired or was already stopped, which was taken as "a value might be waiting — remove it". It was never quite right. If a different goroutine had already received that value, or if the timer had been stopped earlier without firing, there was nothing to drain and the receive blocked. Getting it correct in the presence of more than one goroutine was, in practice, not possible with the API as it stood. ## What Go 1.23 changed Go 1.23 made timer and ticker channels **unbuffered** — capacity zero — and delivery synchronous. The guarantee that came with it is the one to memorise: for any call to `Stop` or `Reset`, no value prepared before that call will be sent or received after it. In other words, after `Stop` returns, a stale tick cannot reach you; after `Reset` returns, the only value you can ever receive is one produced by the new deadline. So the drain is unnecessary. And worse than unnecessary: in exactly the situation it was written for — the timer fired, nobody received — `Stop` returns `false`, the pending value has been discarded by the `Stop` itself, and the following `<-t.C` waits for a send that will never come. Legacy code carried forward without review can deadlock a goroutine on a machine running current Go. The modern forms are plain: ```go t.Stop() t.Reset(interval) ``` and, when a single goroutine owns the timer and simply wants the next deadline, `t.Reset(interval)` on its own. ## The compatibility mechanics Go takes backward compatibility seriously enough that this behaviour change was gated. In Go 1.23 through 1.26 the old asynchronous, buffered behaviour was still available as `GODEBUG=asynctimerchan=1`, and — because GODEBUG defaults follow the `go` line in the main module's `go.mod` — a module still declaring an older language version kept the old behaviour even when built with a newer toolchain. That is worth knowing when you are diagnosing a timer that behaves differently in two services built from the same toolchain: check their `go` lines. Go 1.27 removed that setting. Timer channels are now always synchronous, with no way back. ## Reading Stop's return value today `Stop` still returns a bool: `true` if it stopped a timer that had not yet fired, `false` if the timer had already fired or had already been stopped. What changed is what you may conclude from it. It is a statement about the timer's schedule, not an indicator that a value is parked in a buffer waiting for you — there is no buffer. Code that branches on the bool in order to decide whether to receive is reasoning about a data structure that no longer exists. Two related facts that survive every version: `Stop` does not close the channel — nothing closes a timer channel, because a close would look to receivers like a tick that never happened — and `Reset` on an already-fired timer is fine, it simply schedules the next firing. ## How to talk about this in an interview The strong answer has three beats. State the modern rule (no drain; `Stop` then `Reset`). Explain why the ritual existed (the capacity-one buffer and the stale value). Then name the hazard: the idiom does not merely waste a line now, it can block forever, so porting old timer code to a current toolchain deserves a deliberate pass rather than a compile-and-ship.