Your metrics daemon panics only on the 32-bit ARM build — how do you diagnose it and stop the class recurring?

## Start with what the panic already told you A panic naming an unaligned 64-bit atomic operation, on a build whose `GOARCH` is `arm` or `386`, is nearly self-diagnosing. The stack frame names the function; the function names the struct; the struct has a 64-bit field somewhere after a 32-bit one. On 32-bit ports a 64-bit field needs only 4-byte alignment, while the 64-bit atomic operations need 8, so the field is legal to declare and illegal to touch atomically. The 64-bit builds you develop and test on align it to 8 bytes for free, which is exactly why nobody saw it. Resist the quick fix. Moving the field to the front of the struct works and is guaranteed, but the guarantee covers only the first word of an allocation, so the next person who adds a field above it, embeds the struct, or puts it in a slice of an odd size reintroduces the crash. Declaring the field as `atomic.Uint64` moves the requirement into the type, where a refactor cannot undo it, and has the side benefit of making non-atomic reads of the counter impossible to write by accident. ## Then look for the quiet siblings A 32-bit target changes two things at once: alignment, which fails loudly, and integer width, which fails silently. Having found the loud one, assume the quiet one is there too and go looking: - `int(x)` where `x` is an `int64` byte count, file offset, database identifier or nanosecond timestamp. On the 32-bit build the high bits vanish, no panic, no vet warning, and the daemon simply reports numbers that are too small. - Comparisons and clamps against `math.MaxInt`, which is a different number per target. - Anything assuming a pointer or `uintptr` is 8 bytes, or that a buffer can exceed 2 GiB — `len` returns `int`, so a slice on a 32-bit build tops out around 2^31-1 elements. - Byte-level code that relies on the machine's order or on unaligned multi-byte loads. The search is cheap and mechanical: grep for `int(` around size and time arithmetic, and read the exported structs for fields typed `int` that hold quantities. ## Make the target real in CI The root cause of the incident is not the struct; it is that a supported architecture was never executed. Three levels, in ascending value: 1. **Compile it.** `GOOS=linux GOARCH=arm go build ./...` proves the code exists for the target and catches untyped constants that overflow a 32-bit `int`. 2. **Vet it under the target.** `GOARCH=386 go vet ./...` type-checks the packages with 32-bit widths, so overflowing constants and impossible conversions surface at merge time. 3. **Run it.** `GOARCH=386 go test ./...` on an amd64 Linux runner usually executes directly and reproduces both 32-bit `int` and 4-byte alignment of 64-bit fields, which covers most of this bug class without any device in the loop. For the real `arm` target, `go test -exec <emulator-wrapper> ./...` runs the compiled test binaries under emulation. Step 3 is the one that would have caught this panic, and it is the one teams skip. ## What will not catch it Worth saying explicitly, because candidates reach for these: the race detector instruments memory accesses for happens-before violations and knows nothing about alignment; there is no standard vet check for 64-bit atomic alignment; and building for the target is not running for the target. Coverage on amd64 is also no signal at all, because the same line is exercised there and behaves correctly. ## Close the loop A good answer ends with prevention that does not depend on memory: typed atomics for every counter, explicit `int64` for every size, offset and timestamp in exported types, a named `ByteOrder` on every frame, and the 32-bit CI leg made required rather than advisory. Each of those turns a rule someone must remember into a shape the compiler or the pipeline enforces — and that is the difference between fixing an incident and retiring its class.