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

171–180 of 369 posts

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

#171

Post by tomjakubowski »

LocalH wrote: post #151
throwaway_19sz wrote: post #50

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

I'd believe it. What I'd find harder to believe is that it wasn't really a table with more information than just "list of assigned UUIDs". I'd be really surprised (pleasantly!) if it was only that. I'd figure most startups would make sure that table links to customer info so that they know which customer has a specific UUID, for easy searching and crossreferencing with the main db

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-90c081ce033c, and that particular identifier will actually be an ID of some associated data, not the widget. You can push back and say, "That isn't a widget identifier, can you please look up the widget identifier?" It's better to be able to look that ID up in your ID ⮕ entity type lookup table, and say "the ID you provided is a widget production run ID, which produced a copy of widget a84969be-137a-41ca-97c4-515497184df9. Can you confirm this is the widget you need process X done for?", with a link to the product-facing widget page.

(Also handy for the case where some code was intended to log an ID for one entity, but actually logs the ID for an associated entity with the wrong entity type indicated.)

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

#172

Post by Aurornis »

throwaway_19sz wrote: post #50

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

> One endpoint with its own dedicated team of 3 engineers

> The team had its own kanban board and sprints.

My early jobs were at startups startups with limited resources. Every decision to build something or hire someone was carefully made after much consideration. This story would have looked like fiction to me at the time.

Later in my career I joined a startup like this where every new concern someone could think up turned into a new microservice with new hires to form a new team. It didn't matter how small it was, everything was a reason to hire new people and form a new team. I sat in meetings where the express goal of the quarter was communicated as growing the engineering team.

It was as weird time. We had this same situation where there were 3-4 person teams who had their own sprints and planning sessions where they would come up with more ways to make work for themselves. Some of them moved so slow that they could spend entire sprints doing tiny changes. Others were working on the most over-engineered solutions you'd ever seen for trivial problems.

There was one meeting where I suggested we re-assign some people on a stable project to work on something that we needed urgently, but I got shut down. That would have removed another excuse to hire more people, which would have conflicted with someone's KPIs to grow the engineering team to a specific number

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

#173

Post by ffsm8 »

ryanmonroe wrote: post #169
stanmancan wrote: post #142

Earlier quoted context omitted.

I left a more detailed comment on the parent, but it's definitely not impossible!

The scenario in this post is that the first uuid was created one year before the duplicate uuid. That isn’t possible with v7

You're heavily leaning on "collision like this" to relate to the exact time stamps for your statement to be true.

It's equality possible to interpret the "like this" to the collision itself, without a focus on the 1 year distance between the creation dates.

So I guess both views are valid.

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

#174

Post by recursive »

antonvs wrote: post #143
wolttam wrote: post #114

Earlier quoted context omitted.

The LLM is mechanistically unable to pick something actually random and outside of its training distribution, so... yep.

If you ask it to construct a UUID character by character you should get a somewhat random one, just because of temperature.

But all LLM output is token by token, which isn't too far from character by character in the case of a UUID. Why is this different? I do not know.

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

#175

Post by matt-p »

thecloud wrote: post #113
jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

Thanks for the insight! Mind expanding on what alternatives are being used in high reliability systems instead of UUIDv4?

UUIDv7 is arguably better, because it is entropy plus time.

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

#176

Post by rekabis »

throwaway_19sz wrote: post #50

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

You would think they could automate the entire process by “creating-ahead” a certain number of UUID values in the DB, storing them in memory to reduce DB latency, and then recording the assignment to the DB once it had been assigned.

And the microservice could easily be crafted to only accept assignment requests from other known endpoints.

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

#177

Post by euroderf »

victorbjorklund wrote: post #166
LocalH wrote: post #141

Earlier quoted context omitted.

This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…

If I understand it the Lava lamps are 90% PR/fun. They have a lot of other sources for entropy that scales better.

Ant farm ? Hamster wheels ? Anything critter-driven should provide some entropy.

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

#178

Post by toraway »

jbverschoor wrote: post #117
jbverschoor wrote: post #110

Earlier quoted context omitted.

Changed 3 weeks ago: uuid/src/rng.ts : the random array is const. Every call will share the same random number. Subsequent call will update your old random code, so if you generated something important... good luck The old code used to do a slice() which creates a new copy. Might be unintentional. Although I have no idea how this would pass any tests, as you would think to test generating 2 randomnumbers and hope the…

Didn't actually want to write a test myself.. but I miss Claudia confirmed it. Pretty concearning. Synchronous / serial calls: import rng from './rng'; const a = rng(); console.log('a after first call: ', Array.from(a)); const b = rng(); console.log('a after second call:', Array.from(a)); console.log('b after second call:', Array.from(b)); console.log('a === b (same reference)? ', a === b); console.log('a equals b (s…

Shouldn't your test follow the pattern of how rng() is actually being used in the uuid.ts code internally?

Your test is more-or-less contrived to fail given the tradeoff to avoid repeated memory allocations but that doesn't say much about the actual usage in uuid generation since it's not exported for general purpose use.

Presumably they had some hot path somewhere where rng() is called in a loop and this optimization made sense with awareness that it could be misused as in your example breaking the contract ensuring randomness, which (hopefully) they're not actually doing anywhere.

Unless I'm missing something replacing the package over this with a less vetted implementation seems excessive and possibly even counterproductive.

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

#179

Post by JamesSwift »

ryanmonroe wrote: post #169
stanmancan wrote: post #142

Earlier quoted context omitted.

I left a more detailed comment on the parent, but it's definitely not impossible!

The scenario in this post is that the first uuid was created one year before the duplicate uuid. That isn’t possible with v7

Surely the scenario where he generates the same number of items as he did between 2025 and now, but did it in 1 tick of v7 UUIDs also runs into it?

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

#180

Post by rootlocus »

stanmancan wrote: post #135
filcuk wrote: post #124

Earlier quoted context omitted.

The latest UUID (7?) Uses half random gen, half timestamp. This not only makes it sortable by creation, but would also make a collision like this impossible.

It's still possible in most implementations of UUIDv7. UUIDv7 assigns the first 48 bits for the timestamp in milliseconds. You can generate a lot of UUID's in a millisecond though! Then you have another 12 bits that you can use as you wish; "rand_a". The spec has a few methods they suggest on how to use these bits including 12 bits of random data, using it for sub-millisecond timestamps, or creating a monotonic count…

We have a dedicated snowflake id generator service that returns batch ids. It's also distributed, each service adds its own instance number to the id. When it overflows it just blocks for the next ms. For our traffic, it's never a bottleneck.
Post reply on HN