YHK - yet another hacker news clone

42 points mittermayr 3 hours ago 50 comments

I know what you're thinking... and I still can't believe it, but...

This morning, our database flagged a duplicate UUID (v4). I checked, thinking it may have been a double-insert bug or something, but no.

The original UUID was from a record added in 2025 (about a year ago), and today the system inserted a new document with a fresh UUIDv4 and it came up with the exact same one:

b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd

We're using this: https://www.npmjs.com/package/uuid

I thought this is technically impossible, and it will never happen, and since we're not modifying the UUIDs in any way, I really wonder how that.... is possible!? We're literally only calling:

import { v4 as uuidv4 } from "uuid";

const document_id = uuidv4();

... and then insert into the database, that's it.

Additionally, the database only has about 15.000 records, and now one collision. Statistically... impossible.

Has that ever happened to anyone?! What in the...

samdhar 2 hours ago | parent

The math says no. UUID v4 has 122 bits of randomness, so collision probability for 15K records is N²/(2·2^122) ≈ 2·10^-29. That's somewhere around "fewer collisions per universe lifetime than atoms in your liver." Whatever you're seeing, the culprit is overwhelmingly somewhere else.

Things to check, in descending order of how likely they actually are:

1. Data import / migration / backup restore, perhaps? Did anyone load a CSV, run a seed script, restore a snapshot, or copy rows between environments at any point in the last year? This is what "duplicate UUID" is in 99% of cases. Check git on migrations, ops history on the DB, and ask anyone who might have been moving data around.

2. Application retry / rollback bug maybe? Code path that generates a UUID, attempts insert, fails on constraint violation, retries with the same UUID variable still in scope. Check whether UUID generation lives inside or outside the retry boundary.

3. Older versions of the uuid package in certain bundler environments would fall back to Math.random() instead of crypto.getRandomValues(). What version are you on? Anything <4.x is suspect; modern v8+/v9+ uses crypto everywhere correctly.

4. Could also be a process fork bug. If a UUID generator runs in a child process spawned from a parent that already used the PRNG, the entropy state can get copied. Rare in Node specifically, more historical in old Python/Ruby setups.

If you've ruled all of those out and the row really was generated independently a year apart via crypto.getRandomValues, go buy a lottery ticket. But it's almost certainly cause #1.

uncircle 50 minutes ago | parent

Statistically speaking, does extremely unlikely mean impossible? If it were replicable I'd raise my eyebrow, otherwise it's fair game, no?

As someone that enjoys the unterminable complaints about RNG in the video game scene, I would never trust any human's rationalization of random outcomes.

nubg 47 minutes ago | parent

You are replying to an AI bot

harperlee 40 minutes ago | parent

Would be cool to have a plugin that shows % of bot per user, based on their history of comments.

mschild 44 minutes ago | parent

> Statistically speaking, does extremely unlikely mean impossible?

No, it means extremely unlikely. Collisions can occur, as op just found out, but the chances are so abysmally small that most people don't care.

Any application I have worked on, I always had a pre-save check to see if the UUID was already present and generate a new one if it was. Don't think it ever triggered unless a bug was introduced somewhere but good practice anyway.

nubg 48 minutes ago | parent

Question to fellow HNers, do you recognize that this comment was written by AI?

uncircle 43 minutes ago | parent

I guess not, and I feel dirty now. I'm logging off for the day.

mschild 42 minutes ago | parent

Kind of. It reads a bit too much like tech support you'd get when asking one for help.

prakka 41 minutes ago | parent

No, to be honest. However, as soon as it was pointed out, I checked again and it made sense.

In my opinion, these kind of intuitions have to grow over time. And every time it’s pointed out, you learn. So please, keep pointing it out :).

tirutiru 35 minutes ago | parent

I did not. Post-conditioning by your comment and the other one,I can see some signs such attempting to be unusually comprehensive. The 'atoms in your liver' could be an awkward human trying to be poetic about scales.

I still don't see idiomatic markers of AI so that's scary if your claim is correct.

ssenssei 27 minutes ago | parent

when it started going on about all the different cases in the second bullet point... yeah

speedgoose 22 minutes ago | parent

Yes, stupid comparison with atoms in the liver and a bullet list below? I stopped reading.

nottorp 13 minutes ago | parent

Interesting enough, I skipped it when scrolling through the comments the first time. I think I instinctually do that to most karma whoring comments, no matter if manual or LLM generated.

Only noticed it because I did another pass and saw the replies talking about "AI".

ashleyn 40 minutes ago | parent

There could be a problem with the way the system generates entropy for randomness.

serf 2 hours ago | parent

1 in 4.72 × 10²⁸

1 in 47.3 octillion.

i'd be suspecting a race condition or some other naive mistake, otherwise id be stocking up on lottery tickets.

(lol at the other user posting at the same time about the lottery ticket.. great minds and all that.)

mittermayr 2 hours ago | parent

I fully agree. It makes no sense. Yet...

The only guesses I'm having is that we originally generated UUIDv4s on a user's phone before sending it to the database, and the UUID generated this morning that collided was created on an Ubuntu server.

I don't fully know how UUIDv4s are generated and what (if anything) about the machine it's being generated on is part of the algorithm, but that's really the only change I can think of, that it used to generated on-device by users, and for many months now, has moved to being generated on server.

stubish 2 hours ago | parent

The UUIDv4 collision is statistically extremely unlikely. What is more likely is both systems used the same seed. This might be just a handful of bytes, increasing the chance of collision to one in billions or even millions.

AntiUSAbah 1 hour ago | parent

You let users generate a UUID?

To be honest, the chance that you are doing something weird is probably higher than you experiencing a real UUID conflict.

How did your database 'flag' that conflict?

mittermayr 1 hour ago | parent

user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of app, where the same invoice must not be stored twice. So we used to generate a fresh invoice_id (uuidv4) on the user's device for each new invoice, and a double-send of that would automatically be flagged server-side (same id twice). This has since moved on to a server-only mechanism.

The database flagged it simply by having a UNIQUE key on the invoice_id column. First entry was from 2025, second entry from today.

lazyjones 18 minutes ago | parent

Better check what crypto.js is actually doing in your exact setup. Weak polyfills exist...

beardyw 2 hours ago | parent

Just a stupid question, but why not append the date, even in seconds as hex. It's just a few bytes and would guarantee that everything OK now will be OK in the future?

mittermayr 2 hours ago | parent

yeah, any sort of additional semi-random data could've helped prevent this, I'm sure. That, however, is also kind of the idea of UUIDv4, it has lots of randomness and time built in already.

flohofwoe 1 hour ago | parent

UUID v4 consists of only random bits, no timestamp info.

mittermayr 1 hour ago | parent

oh, interesting, I didn't know that and this could possibly be part of the problem perhaps depending on what's used as the seed.

flohofwoe 1 hour ago | parent

You can just use a different UUID variant which includes timestamp data instead (e.g. v1 or v7), there are also variants which include the MAC address.

pan69 1 hour ago | parent

> but why not append the date

And use uuid v5 to hash it :)

wg0 2 hours ago | parent

Would the UUID v7 be more collision proof? Hard to say because it takes time into account but then the number of entropy bits are reduced hence the UUID generated exactly at the same time have more chance of a collusion because number of entropy bits are a much smaller space hence could result in collusions more easily.

Thoughts?

AntiUSAbah 1 hour ago | parent

You open up every millisecond a new block. Should be even more unlikely

naikrovek 2 hours ago | parent

The chance of a UUIDv4 collision is very low, but it is never zero.

If everything is done properly, then this is very likely the one and only time anyone involved in the telling or reading of this account will ever experience this.

dalmo3 1 hour ago | parent

Classic gamblers fallacy!

jordiburgos 2 hours ago | parent

Please, do not use b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, I checked my database and I was using it already.

mittermayr 1 hour ago | parent

I knew it, we're all getting the same cheap UUIDs and the good ones are reserved for the big dogs.

Galanwe 1 hour ago | parent

uuid.uuidv4() recently switched to "adaptive entropy" instead of "xmax entropy" in an effort to save costs on non-premium users.

robshep 1 hour ago | parent

I'm using 16b55183-1697-496e-bc8a-854eb9aae0f3 and probably some more too. I suppose if we all post our list here, then we can all check for duplicates?

mittermayr 1 hour ago | parent

We should all send our already-generated UUIDs to a shared database, we could just put it on Supabase with a shared username/password posted on HN, so we can all ensure that after generating a UUIDv4 locally, it's not used by anyone else. If it's in the database, we know it's taken.

It's a super simple mechanism, check in common worldwide UUID database, if not in there, you can use it. Perhaps if we use a START TRANSACTION, we could ensure it's not taken as we insert. But that's all easy, I'll ask Claude to wire it up, no problem.

broken-kebab 35 minutes ago | parent

But then I will claim I have already used all the UUIDs in my spreadsheets, and my lawyer will send cease&desist letters to every database.

volemo 1 hour ago | parent

A site previously posted here could be useful: https://everyuuid.com/

jsnell 1 hour ago | parent

You can check https://everyuuid.com/ for collisions.

adyavanapalli 1 hour ago | parent

What you're talking about is so extremely rare that it's much more likely that the entire Earth is destroyed by an asteroid right this inst...

tumdum_ 1 hour ago | parent

Poorly seeded prng.

jdthedisciple 42 minutes ago | parent

most likely the culprit indeed

nswango 29 minutes ago | parent

But I used nonstandard nonces!

glaslong 51 minutes ago | parent

Buy some lava lamps

AndreyK1984 33 minutes ago | parent

Why not to have timestamp-uuid instead ?

dgellow 21 minutes ago | parent

How confident are you that your machines clocks are in perfect sync? What about the risk of clock drift + correction, or hardware issues?

ares623 28 minutes ago | parent

Buy a lottery ticket

leni536 25 minutes ago | parent

It's not happening by chance, there is a bug somewhere.

From what I skimmed the package should just call to the js runtime's crypto.randomUUID(). I think it should always be properly seeded.

I think it is extremely unlikely that the runtime has a bug here, but who knows? What js runtime do you use?

not_math 21 minutes ago | parent

Reminds me of some code I saw running in production. Every time we added a new entry, we were pulling all the UUIDs from this table, generating a new UUID, and checking for collisions up to 10 times.

throwaway_19sz 20 minutes ago | parent

Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’ UUID. My pal asked wtf. It turned out this service had its own DB to store every previously issued UUID. Requests were handled as follows: it would generate a UUID, then ‘validate’ it by checking its own database to ensure the newly generated UUID didn’t match any previously generated UUIDs, then insert it, then return it to the client. Peace of mind I guess. The team had its own kanban board and sprints.

NKosmatos 19 minutes ago | parent

> I thought this is technically impossible

Actually it's not impossible, but very very improbable.

P.S. You should play a lottery/powerball ticket

P.P.S. Whenever I use the word improbable, the https://hitchhikers.fandom.com/wiki/Infinite_Improbability_D... comes in mind