Ask HN: We just had an actual UUID v4 collision... • Hacker News Board

Re: Ask HN: We just had an actual UUID v4 collision...

#41

Post by broken-kebab » Fri, May 08, 2026, 10:24 AM UTC

mittermayr wrote: post #24

robshep wrote: post #22

Earlier quoted context omitted.

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?

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 TRANS…

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.

Re: Ask HN: We just had an actual UUID v4 collision...

#42

Post by AndreyK1984 » Fri, May 08, 2026, 10:26 AM UTC

Why not to have timestamp-uuid instead ?

Re: Ask HN: We just had an actual UUID v4 collision...

#43

Post by nswango » Fri, May 08, 2026, 10:29 AM UTC

jdthedisciple wrote: post #36

tumdum_ wrote: post #25

Poorly seeded prng.

most likely the culprit indeed

But I used nonstandard nonces!

Re: Ask HN: We just had an actual UUID v4 collision...

#44

Post by ares623 » Fri, May 08, 2026, 10:30 AM UTC

Buy a lottery ticket

Re: Ask HN: We just had an actual UUID v4 collision...

#45

Post by ssenssei » Fri, May 08, 2026, 10:31 AM UTC

nubg wrote: post #30

samdhar wrote: post #2

[flagged]

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

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

Re: Ask HN: We just had an actual UUID v4 collision...

#46

Post by leni536 » Fri, May 08, 2026, 10:34 AM UTC

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?

Re: Ask HN: We just had an actual UUID v4 collision...

#47

Post by speedgoose » Fri, May 08, 2026, 10:36 AM UTC

nubg wrote: post #30

samdhar wrote: post #2

[flagged]

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

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

Re: Ask HN: We just had an actual UUID v4 collision...

#48

Post by dgellow » Fri, May 08, 2026, 10:37 AM UTC

AndreyK1984 wrote: post #42

Why not to have timestamp-uuid instead ?

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

Re: Ask HN: We just had an actual UUID v4 collision...

#49

Post by not_math » Fri, May 08, 2026, 10:38 AM UTC

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.

Re: Ask HN: We just had an actual UUID v4 collision...

#50

Post by throwaway_19sz » Fri, May 08, 2026, 10:39 AM UTC

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.