We've been debugging an issue today after introducing uuid-utils into our backend workers, which use Celery. Celery workers use fork(2) (at least in some configurations) to spin up worker processes.

The rand crate, which rust's uuid crate uses if you pass the fast-rng crate, doesn't seem to reseed the RNG on a fork. In Rust land, I suppose this normally isn't an issue because it seems pretty rare to use fork. In python, it's a lot more common, causing a situation where the rng isn't reseeded when forking out celery workers.

Enjoy some repros:

fn main() {
    // first, just make sure the rng is initialized in the parent process
    let _ = uuid::Uuid::new_v4();
    let tid = unsafe { libc::fork() };
    println!("{:?} from {tid}", uuid::Uuid::new_v4());
}

import sys
import uuid_utils
sys.modules["uuid"] = uuid_utils
import os

import uuid

a = uuid.uuid4()
print(f"a = {a}")
os.fork()
b = uuid.uuid4()
print(f"b = {b}")

I suppose this is technically not a bug, I'm just interested in your take on this. Ultimately it's kind of a culture issue that python forks, but as of now it's a tradeoff between the "just works"-ness of this as a library and generating uuids very quickly.

Versions

• uuid_utils 0.6.1
• cpython 3.12.0
• macos and linux