My goal is determinism specifically around message timings/execution in replay. We don't currently advertise runtime determinism, we also don't promise fixes fo

My goal is determinism specifically around message timings/execution in replay. We don't currently advertise runtime determinism, we also don't promise fixes for determinism in your code. For message timing, the algorithm should be stable - it generates a timeline for when messages should be executed by each message handler, and will pause further executions to wait on handlers that "should have" finished, but haven't due to running too slow. Ties are broken by the handler name or data source name. I wrote a bit about it here https://basisrobotics.tech/2024/09/02/determinism/ https://basisrobotics.tech/2024/09/02/determinism/ but didn't go deep into the implementation. If your own code isn't deterministic you will have differences, but this eliminates the biggest classes of nondeterminism when running tests (threading timings, message handling races). I don't think Copper claims to offer more than this either, but I can't speak for them.