Our own package wasn't adding anything.

That I'm not so sure about. Our bespoke uuid package was introduced in #556 as a replacement of the predecessor to github.com/google/uuid of all things. Apparently backoff-retry on EPERM from the random source was a motivating factor. It probably didn't help that the uuid dependency at the time did this unconditionally:

• UUID generation in implicit init() causes issues if no /dev/urandom is available #782
• UUID package improvements #792

so I am concerned that just doing the equivalent of reverting #556 is going to introduce regressions. Could we wrap google/uuid in the retry logic to retain the existing behaviour?

I vaguely remember reading through that issue. I also found this comment by Stevoo kinda unresolved:

#782 (comment)

Specifically, we never learnt what the real error actually was 🤷‍♂️

so I am concerned that just doing the equivalent of reverting #556 is going to introduce regressions. Could we wrap google/uuid in the retry logic to retain the existing behaviour?

We could, but that was back in 2015 and I expect there have been many improvements since then.

Most of the places we create a uuid we don't have err in the return, so we couldn't fail more cleanly than panicking too.

Without a good understanding of why the workaround was needed, I think its sensible to remove it and see if we get any tickets during our beta period.

Just for fun, I created a billion uuids on my laptop using the google library. It took 5m39s and didn't panic once. I know that doesn't recreate whatever issue we had before, but I thought I'd try it.