Hard to believe that all their customers had written their code to work with signed IDs though.
Honestly I would expect that to break more users code (and in weirder ways) than just changing the type. It's unclear from the story how the type was exposed though.
Yeah, this was my immediate thought as well, but if the spec for the API says signed int, then at least you're defensible: you haven't broken the letter of the spec, even if you're pounding on the spirit of the spec pretty hard. You have a fairly reasonable likelihood that most/all of your customers have implemented to your spec, and therefore any negative consequences are down to secondary effects of how they handle the negative values, not directly because of failure to be able to store them.
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.
Came here to say exactly this. Programming languages usually default to signed, but if you're storing these things in databases it's common to explicitly choose unsigned, since ID's are virtually always unsigned and it gives you twice the space until you run out.
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.
Postgres doesn’t have unsigned column types out of the box. There’s an extension that enables it, but you’d have to know about that (which you should, if you’re managing a DB, but I digress).
MySQL does have unsigned ints out of the box, FWIW.
One of them would presumably break every customer if the API was properly documented.
I'd believe it. Not sure when this is, but if it's a few years old and business software, they could probably asume everyone uses java, which doesn't even have unsigned integers.
Right but just because it's `int id` doesn't mean all code that uses it will still work when it's negative.
True, but it does seem like the best alternative here. If it's a SOAP API in 2005 for business customers, for example, then it sounds like the least bad option of the four (tell consumers to update, hold up the whole company's deployment, push negative ints, or push longs). I'm just saying that to me, it isn't hard to believe this was the best option here.
With $MY_JOB in java, that was my assumption