Two questions about the fork boundary. The snapshot is taken once when the process calls listen, so every later instance is a clone of the same frozen memory image, and anything seeded during init is identical across every clone in every region. That is exactly what the Linux vmgenid driver exists for, and it is why Lambda SnapStart had to ship explicit reseeding guidance. I could not find entropy, RNG or reseed anywhere in the runtime, performance or security docs, so is there a post-restore reseed hook, and does it fire before the first accept?
The other one is syzy. CRDT.md says eviction is operator-driven, that PRUNING.md is a design-stage contract and not yet code, and that a replica lagging beyond the hold window may transiently observe the departing duplicate, while the product headline offers scale to zero when idle, which mints offline replicas continuously. Who calls syzy_evict in the managed product?
The other one is syzy. CRDT.md says eviction is operator-driven, that PRUNING.md is a design-stage contract and not yet code, and that a replica lagging beyond the hold window may transiently observe the departing duplicate, while the product headline offers scale to zero when idle, which mints offline replicas continuously. Who calls syzy_evict in the managed product?