The Best Worst Hack That Saved Our Bacon

The file format is obsolete (it assumes a fixed number of terminal lines per system) and has unfixable locking issues, so it has to be replaced anyway.

If a client application makes an assumption about this, then their engineers will accept this as being their bad and will fix it.

I'd defend this as being pragmatic - minimising disruption to clients instead of the more 'correct' solution of changing the API. I'm hoping that they managed to roll out the new API update alongside the old one and avoid a 'big bang' API change with this. Sometimes this isn't possible, but it's great when that works out.

TBF using the negative range could also break callers distinguishing between signed and unsigned if they’d used the latter on their side depending how the API was documented.

Like, instead of using negative primary keys, they could have also just have converted to an unsigned int32. I would assume both of those would break a bunch of customer implementations though.

That said, to your point, there was almost certainly someone comparing IDs to determine recency, and during the transition from large-positive to large-negative, that would absolutely cause havoc.

I'd be curious if their API spec actually said anywhere that the IDs increased consistently.

If they expose them as string and mention they're opaque? Then customers who parse them to uint will get bugs and be unhappy.

Did they expose them as ints? Customers who used uints will be unhappy.

At `jobs[-2]` the front-end parsed the ids (exposed as strings, but ints under the cover).

The backend left them alone.

That caused some issues when building out shared libraries.

But 2038 is gonna be awesome!

A few "alter table" commands cascades to an operational PITA.

I think he did a pretty bad job of explaining it if that’s the case though.

A primary key is almost an implementation detail - a key that an API knows about something is one of many things that might point to this thing, might need to change, and generally might need a different representation (so don't make it your primary key.)

I also tell people to just use the bottom of any primary key space (when choosing monotonic stuff) but so many engineers just complain that they dont like the numbers (and yet many of them have had to deal with the migration a few years later so ... enjoy that I guess.)