A Go worker minting reset tokens emits repeats after every restart. How do you find the cause?

## Read the symptom first "Repeats after every restart" is unusually informative. It says the generator has state, that the state is rebuilt at process start, and that it is rebuilt the *same way* each time. A cryptographic source cannot behave like this: `crypto/rand` holds no seed you supply and draws from the operating system, so two processes started a second apart produce unrelated output. A statistical generator behaves exactly like this the moment its seed is a constant, a configuration value, or anything the environment supplies identically on each boot. Before reaching for tools, that reasoning already narrows the search to one import. ## Find it mechanically ``` $ go list -deps ./cmd/resetworker | grep '^math/rand' math/rand/v2 ``` `go list -deps` prints the full transitive package list for a binary, so this answers "does anything this worker links in use the statistical generator" without reading a line of code. If it comes back empty, the cause is elsewhere and you have ruled out the whole family in one command. If it prints a match, walk the callers until you reach the minting function. The two shapes you are looking for: ```go var gen = rand.New(rand.NewPCG(0x5eed, 0x5eed)) // math/rand/v2 func resetToken() string { return strconv.FormatUint(gen.Uint64(), 36) } ``` and the quieter one, where the intent was correct and an error branch undid it: ```go if _, err := crand.Read(b); err != nil { // "this can never happen, but just in case" fillFromSeededGenerator(b) } ``` The second is the more dangerous, because a reviewer skimming for imports sees `crypto/rand` at the top of the file and moves on. It also fails in a lumpier way: it only produces repeats when the branch fires, which is why intermittent duplication is worth chasing even when the happy path looks right. ## Where the habit comes from This is characteristically a porting bug. In several other ecosystems the idiomatic setup is a global generator seeded once at startup, and the reviewer's rule there is "make sure you seeded it". Someone carries the rule across, seeds a Go generator from a config value or a constant so that tests are reproducible, and ships. In Go both halves of that habit are wrong: the top-level `math/rand` functions have been randomly seeded since Go 1.20 and `math/rand/v2` has no top-level `Seed` at all, so there is nothing to remember to do — and none of it was ever the reason the package is unsuitable for secrets. ## Fix, and do not soften the fix Replace the generator with `crypto/rand.Text()`, which returns a 26-character token in one call and cannot fail. Delete the fallback branch entirely rather than improving it — there is no correct content for it, and since Go 1.24 `crypto/rand.Read` does not return an error to trigger it. Resist two tempting non-fixes: - **Adding entropy to the seed.** A better seed does not change what the generator promises; an observer of a few outputs still recovers the stream. - **Hashing the output.** A hash of a predictable value is a predictable value. ## Prove it, do not assert it The defect survived review because nothing tested the property. Add a test that exercises the generator across two *fresh processes* — the state that repeats only repeats on a restart, so a single test binary calling the function a thousand times will pass happily on the broken code. Running the mint function in a subprocess twice and comparing the two sets is the check that would have caught it, and it keeps catching it if someone reintroduces a seeded generator later. Back it with a structural guard: keep secret generation in one small package, and make an import of `math/rand` or `math/rand/v2` from that package a build failure or a review rule. Mechanical guards outlast the memory of the incident. ## Then handle the tokens already out there The engineering fix stops new bad tokens; it does nothing about the ones already issued. Every outstanding reset token generated by the deterministic path must be treated as known to an attacker: invalidate them all, force affected users to request a new link, and check the audit log for reset completions that do not correspond to a request. Shipping the code change and leaving the old tokens valid is the half-fix that turns a bug into an incident. ## Related symptoms worth ruling out If `go list -deps` finds nothing, look for a token that is *derived* rather than generated — a hash of the user id and a timestamp, a database sequence, a value cached per user — or for a test double left wired into the production build, such as a replaced `crypto/rand.Reader` behind a build tag. All three produce repeatable output while every import looks correct.