The Comedy of UUID Errors: Real Support Tickets I've Seen

UUIDs: meant to prevent collisions, confusion, and chaos.

And yet... chaos finds a way.

Here are some real support tickets, bug reports, and facepalm-worthy stories involving UUIDs — and the lessons they taught us (sometimes painfully, sometimes hilariously).

1. “Why are half our user IDs the same?”

Issue: A team noticed that over 50% of new users were getting the same UUID.

Root cause: Someone stubbed UUID generation in test mode like this:

Then forgot to unmock it.

💡 Lesson:

• Always use dynamic mocks for UUIDs
• Static UUIDs make for... very identical databases

2. “I pasted the UUID, but it didn’t match”

Issue: A user insisted the UUID in the error log exactly matched the one in their request.

It didn’t.

Turns out, when copying from a formatted email, the UUID came with a non-breaking space at the end.

💡 Lesson:

• Trim inputs (but carefully)
• Hidden characters love to ruin your day

3. “These truncated UUIDs are colliding!”

Issue: Two unrelated events had the same ID.

Root cause: The devs decided to store only the first 8 characters of each UUID for “brevity.”

Which, as any entropy-loving human knows, drops you from 122 bits of randomness to 32.

Enough for a handful of collisions on day one.

💡 Lesson:

• Don’t truncate UUIDs
• If you need shorter IDs, use ULIDs or hashids

4. “Everything was fine until someone added quotes”

Issue: A UUID lookup stopped working after a config change.

Root cause: Someone changed a config file and added quotes around a UUID... which was already a string.

Now it became:

The system did a literal string match, quotes and all.

💡 Lesson:

• Watch your serialization
• Sometimes your biggest bug is... extra enthusiasm with quote marks

5. “Our database is full of ‘null’ UUIDs”

Issue: The app sent uuid = null — and the DB gladly inserted it.

Root cause: The UUID generation function silently failed (bad entropy source), returning null.

The dev assumed:

...would save the day. It did not.

💡 Lesson:

• Always check that UUIDs are valid before inserting
• Defensive coding is not just a good idea — it’s necessary

6. “UUIDs are changing... but not really?”

Issue: A batch job generated new UUIDs for each user... but some were still “equal.”

Root cause: The system was comparing UUID bytes to UUID strings — and treating mismatches as equal due to fallback coercion in JavaScript.

💡 Lesson:

• Always compare the same format (bytes vs string vs int)
• Be explicit about your UUID comparisons

7. “Someone tried to sort UUIDv4s...”

Issue: The team used ORDER BY uuid ASC in their analytics dashboard.

Result: Events were all over the place — random ordering, nonsensical timestamps.

💡 Lesson:

• UUIDv4s are not sortable
• Use UUIDv7, ULIDs, or a separate created_at field

8. “Why are these UUIDs invalid on iOS but fine on Android?”

Issue: A mobile app parsed UUIDs fine on Android, but iOS rejected some of them.

Root cause: The API occasionally returned UUIDs in uppercase. iOS (specifically older NSUUID usage) was strict about lowercase + hyphenated format.

💡 Lesson:

• Be consistent in UUID formatting
• Stick to lowercase, hyphenated format for max compatibility

Honorable Mentions

• “We stored UUIDs as `VARCHAR(36)` and then wondered why joins were slow.”
• “The UUID column had no index. That bug report took a week to debug.”
• “A user reported their UUID didn’t work — turns out they were reading it aloud over the phone.”

Final Thoughts

UUIDs are beautifully designed — but humans are not.

Most bugs come not from UUIDs themselves, but from assumptions, truncations, or creative formatting adventures.

So the next time someone says:

> “Let’s just slice off the first 8 characters…”

Hand them this article. Then send them on vacation.

🧃 UUIDs are universal. But mistakes? Universally human.