Reading about it, the FoundationDB testing does look very good. If you control all of the atomic events and build a fuzzer on top, you can indeed end up with re

Reading about it, the FoundationDB testing does look very good. If you control all of the atomic events and build a fuzzer on top, you can indeed end up with reproducible scenarios testing concurrency, up to the atoms' scope. In the async scenarios as with Tokio and Flow(which I just learned about, cheers), the atomicity extends to the scheduler yields, which is already pretty good. It cannot test e.g. atomic memory operations/memfences etc but it can test in a fairly fine-grained way. However, my original point still stands: you can only do this if you control all of the system within your particular scheduler. In real world scenarios you are more likely to encounter: 1. Some database written in C 2. Some storage layer maintained by AWS/Azure/GCP 3. Some messaging layer written in Go 4. Failover modes of the Kubernetes/Hashicorp stack 5. Your node.js webserver named "backend" 6. Some performance-sensitive component written in Rust This sort of testing just does not apply