Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

361–369 of 369 posts

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

#361

Post by erikerikson »

keeganpoppen wrote: post #360
erikerikson wrote: post #263

Earlier quoted context omitted.

No one has yet defined the scale but almost all of the real world scenarios people are actually encountering would be handled by either of the offered solutions.

as would be a million things that don’t involve using uuids at all. it literally means nothing to say “this can be handled by centralizing your uuid store”… if you do that, you DON’T NEED UUIDS. THAT IS THE POINT!

You seem to be insisting that UUID meets the promise of it's name, despite the long standing documentation to the contrary. Is that your intention?

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

#363

Post by arslantoor »

BTW, it never happened to me, I have been working for more than 7 years as a developer maintaining over 1M plus records, but the twist is that we used to generate UUID by timestamps, which is now automatically handled by uuidv7, where the first half is our timestamps and the second half random number, so collisions never happen. In your case, you must be shifted to UUIDv7 without making any change, or just generate using a timestamp

But yeah, collision is expected in random generation; a UUIDv4 is a 128-bit number. If you subtract the bits used to specify the version and variant, you are left with 122 bits of pure randomness.That means there are $2^{122}$ possible combinations, where each 100 combination has chances of collision by 50%

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

#365

Post by DarkUranium »

connorgurney wrote: post #341
tomjakubowski wrote: post #171

Earlier quoted context omitted.

That sort of table can be quite handy when every entity in the business's data stew is identified with a UUID, and there is no way of telling just from looking at an identifier what kind of entity it is. Particularly when the business has disparate databases and/or microservices with their own sets of UUIDs. In such businesses, inevitably, someone will ask you to run process X for widget 8dbcd950-14c1-4877-a8b0-90c08…

Stripe handle this interestingly, with a prefix to the ID indicating the type of entity. https://dev.to/4thzoa/designing-apis-for-humans-object-ids-3...

AWS as well, and I've done this myself, too.

It really helps debugging.

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

#366

Post by DarkUranium »

tracker1 wrote: post #159
stubish wrote: post #9

Earlier quoted context omitted.

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.

The shim for node:crypto in the browser is likely a weaker implementation in JS than the node implementation... you can cheat and use the browser itself to get a UUIDv4... function uuid4() { var temp_url = URL.createObjectURL(new Blob()); var uuid = temp_url.toString(); URL.revokeObjectURL(temp_url); return uuid.split(/[:\/]/g).pop().toLowerCase(); // remove prefixes }

No need for this dance in a modern browser: `crypto.randomUUID()` is a thing nowadays.

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

#367

Post by DarkUranium »

QuercusMax wrote: post #243

I lost all confidence in the infallability of software RNG when I was working on an assignment for Data Structures a million years ago (2000?). The assignment was simple: simulate a 2D random walk where you randomly go NSEW, and run 100 cases, collecting stats as to how long it takes to return to the origin. Super easy assignment, wrote it up probably in C++ (maybe just C?), and ran it on my linux box (probably Debia…

I mean ... rand() is notoriously bad, plenty of actually good options out there. Even back in 1990s.

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

#368

Post by keeganpoppen »

erikerikson wrote: post #261
keeganpoppen wrote: post #256

Earlier quoted context omitted.

literally the whole point of randomly generating UUIDs is that you don't need to check for collision. that's what the "U"s are for. that is the abstraction that is supposedly being provided. "using " is not in any way a "scalable solution" for that with no other context. nor is just throwing out . the whole point is that it is a global (well, per name, "universal") abstraction that can, in practice, have holes that m…

I totally appreciate what you are complaining about. It's always been part of the documentation for a UUID. Having had Martin Fowler as a colleague and meeting with him weekly for a bit, I'd expect him to nod along with what I've written. It's standard knowledge and part of the technical corpus. As is actually distributed unique ID generation which is also not hard.

well it’s especially not hard when you turn it into a completely different problem

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

#369

Post by dylanhouli »

D2OQZG8l5BI1S06 wrote: post #253
e12e wrote: post #121

Some discussion here: https://github.com/uuidjs/uuid/issues/546 Eg: > FWIW, I just tested crypto.getRandomValues() behavior on googlebot and it is also deterministic(!)

That makes sense. I'm not sure why anybody would generate UUIDs in browsers though, it seems to defeat the purpose.

> I'm not sure why anybody would generate UUIDs in browsers though, it seems to defeat the purpose.

How about for offline-first apps?

Post reply on HN