Since Go 1.24 crypto/rand.Read never returns an error. What changed, and how should code handle it?

## What the contract says now ```go func Read(b []byte) (n int, err error) ``` The signature has not changed and cannot change — it is part of the standard library's compatibility promise. What changed in Go 1.24 is the documented behaviour: `crypto/rand.Read` always fills `b` completely and never returns an error. The two return values are still there; they are simply no longer interesting. ## Why the error was removed rather than kept On every operating system Go supports, the randomness source is a kernel generator that cannot fail on a running system. It is seeded once at boot and then produces bytes indefinitely; there is no pool to exhaust and no per-call failure mode to report. The error return was therefore describing a condition that essentially never occurred. An error that never occurs is worse than no error at all, for two reasons. First, it is untestable. Nobody exercises the branch, so whatever is written in it is unreviewed code that will run for the first time in the worst possible circumstances. Second — and this is the reason the change was made — engineers fill that branch with a fallback. The shape is depressingly consistent: `if _, err := rand.Read(b); err != nil { /* use a seeded generator instead */ }`. The author's instinct is availability: the service must keep issuing tokens. The effect is that a condition which would have been loud and obvious becomes silent and catastrophic — the service keeps running and every token it mints from then on is predictable. Removing the error removes the invitation. So the failure is now handled the only way that is actually safe: the program stops. It is not a recoverable panic you can wrap in a deferred `recover` and paper over. If the machine cannot produce random bytes, a service that mints reset tokens has nothing useful to do. ## What to write ```go key := make([]byte, 32) rand.Read(key) ``` That is complete and correct. If a linter in your pipeline flags unused return values, `_, _ = rand.Read(key)` satisfies it without implying there is something to check. Keeping an `if err != nil` around the call is not a bug — it is dead code — but what goes *inside* it matters enormously, and the only defensible content is a hard stop, which the runtime already does for you. On Go versions before 1.24, the check earned its keep: a short read was at least theoretically possible, and code that ignored `n` could proceed with a partly zero-filled buffer. If you maintain a library that still supports older toolchains, keep the check; just make sure the branch aborts rather than substituting a weaker source. ## The one remaining way it can fail `crypto/rand.Reader` is a package-level variable of type `io.Reader`. If it still holds the default value, `Read` goes straight to the operating system and cannot fail. If something has assigned a different reader to it, `Read` calls `io.ReadFull` on that reader instead, and whatever error that reader returns comes back to you. This matters in practice because replacing `Reader` is a known testing trick: swap in a deterministic reader so a test can assert on a fixed token. It is a sharp tool. A test that mutates a package-level variable affects every other test in the process, and a build tag or an initialisation path that leaves the replacement wired up in a production binary is a genuine incident — every value the service generates becomes the deterministic sequence the test wanted. Prefer designing the code so the source is injected as a parameter, and if you do replace `crypto/rand.Reader`, restore it with a deferred call in the same test. ## The reviewer's checklist - Is there an error branch around `crypto/rand.Read`? If so, does it contain a fallback generator? That is the bug. - Does any code use `n` from the return to decide how much of the buffer is valid? Since 1.24 that is always `len(b)`; before it, ignoring a short read was a real defect. - Is `crypto/rand.Reader` assigned anywhere outside a test? That is where a "never fails" call starts failing, or worse, silently succeeding with values somebody chose.