4 ms·

I encountered a similar bug at the same company with far worse results. Won't say any specifics about the product impact, but our backend passed around two dif

I encountered a similar bug at the same company with far worse results. Won't say any specifics about the product impact, but our backend passed around two different kinds of user IDs. Each user had two different IDs, and the ID spaces overlapped. User Alice could have an ID in space 1 that is the same as Bob's ID in space 2. At some point, at least one function expected a "space 1" ID but was being passed a "space 2" ID. This meant that content meant for Alice was shown to Bob and vice versa. None of the data was private in this case, so there was no legal problem, but it was pretty embarrassing. I suggested using strong types for the ID spaces instead of `int`, but left the company before implementing any of that.

Quekid5 4y ago
Oof, I'm happy it was just non-private data! Regardless, this makes an excellent case for strongly typed wrappers as you mention at the end. Our general approach is to use UUIDv4 for identifiers (so the chance of mistaking-one-for-another instantly leads to "not found"), but sometimes you don't have a choice. In those cases it's super-important to have strongly typed wrappers.
Twirrim 4y ago
Similar kind of thing, one company I worked for we had two smart-card/badges, I can't remember why. It may have been nothing more unusual than one was the building card, one was the company one. They had an overlapping ID space. Swipe the wrong one on the printer and you got someone else's print job. In my case I accidentally caused a Senior Director's print job to be printed, and luckily it wasn't anything sensitive. I had no end of trouble trying to get IT to accept that this was actually a problem.