A Go service numbers ticket statuses with iota and stores them as ints. What breaks when someone inserts a new status in the middle of the const block?

### The scenario A support-ticket workflow service declares its statuses the idiomatic way: ```go type Status int const ( StatusOpen Status = iota StatusPending StatusClosed ) ``` The numbers are written to a `status` integer column, published on an internal queue and counted in a dashboard. Someone adds a triage step and, reasonably enough, puts it where it belongs in the workflow: ```go const ( StatusOpen Status = iota StatusTriage // inserted here StatusPending StatusClosed ) ``` ### What actually happens `iota` is the index of the line, so `StatusPending` moved from 1 to 2 and `StatusClosed` from 2 to 3. Nothing in the language notices. The constants have a defined type, but the *values* are ordinary integers and the numbering is an emergent property of line order, not a declaration of intent. Every existing row storing 1 now means `StatusTriage` to the new binary; every row storing 2 means `StatusPending`. Two versions of the service running side by side during a rollout disagree about what a queue message means. The on-call symptom is not an error. It is closed tickets reappearing as pending, a dashboard whose status histogram shifts by one bucket at deploy time, and alerting rules that stop matching. Nothing panics, nothing logs, and the offending diff line looks like a one-word addition. ### Why the compiler cannot help Go has no enum type. `Status(2)` is a legal conversion from any integer, a value decoded from JSON or scanned from a database column is just a number, and a `switch` over `Status` that has no case for a value simply falls through. There is no ordinal keyword to be stable, no exhaustiveness check, and no persistence metadata for the compiler to compare against. The safety you feel from `type Status int` is real but shallow: it stops the wrong *type* being passed, never the wrong *number*. ### The design fix: stop letting position define the contract Rank these by how much you can change: 1. **Persist the name, not the number.** A `status` column holding `"pending"` cannot be renumbered by an edit to a const block, is readable in a query, and makes an unknown value obvious. It costs a few bytes and a mapping function at the boundary. For anything crossing a process, this is usually the right call. 2. **Pin the values explicitly and treat them as append-only.** Write `StatusOpen Status = 1` and so on, with a comment saying the numbers are a stored contract. New statuses get the next free number regardless of where they belong in the workflow; retired ones leave their number behind, marked `_` or a comment, never reused. 3. **Keep `iota` for in-memory values only** — flags, priorities, state that never leaves the process — and convert explicitly at every boundary. The common mistake is to "fix" the ordering problem by sorting the const block or by moving a constant to keep the workflow readable. Readability of the block is worth nothing next to the stability of a stored number. ### The mechanical guards Generating the `String()` method with `//go:generate stringer -type=Status` does more than pretty-print. The generated file contains a function with an array-index expression per constant, so if a value moves, the generated index no longer matches and the package fails to compile with an invalid-array-index error. That converts a silent renumbering into a build failure — provided regeneration is a deliberate step and not something a pre-commit hook does silently. On top of that, a golden test is cheap and catches everything the generator does not: assert both the number and the string of every constant. ```go func TestStatusWireValues(t *testing.T) { want := map[Status]string{ 1: "StatusOpen", 2: "StatusPending", 3: "StatusClosed", } for v, name := range want { if got := v.String(); got != name { t.Errorf("Status(%d) = %q, want %q", int(v), got, name) } } } ``` A reviewer who sees that test fail knows immediately that a stored contract changed, which is exactly the signal the const block itself cannot give. ### If it has already shipped Stop the rollout before both numberings are live at once. Decide which numbering is authoritative — almost always the old one, because the data is already written — restore it by pinning explicit values, and give the new constant a number at the end. If mixed data was written, you need a mapping from the affected time window, keyed by whatever else distinguishes the rows, and that is usually painful enough to be the argument for storing names next time. ### Boundary validation, either way Whichever representation you choose, parse rather than convert at the edge: a function that maps an incoming integer or string to a `Status` and returns an error for anything unrecognised. It costs one small function and it turns "tickets are in the wrong state" into a rejected message with a clear log line.