Yes, the stdlib asyncio event loop does have deterministic scheduling, but that's an implementation detail and I would not rely on it for anything critical. Other event loops - for instance trio [1] - explicitly randomize startup order so that you won't accidentally write code that relies on it.
That sounds familiar...
https://stackoverflow.com/questions/39980323/are-dictionarie...
I get it, but "ecosystems" of async runtimes have a pretty big cost.
Don't you need something like a network clock to get deterministic replay?
It can't use immediate return on replay, or else the order will change.
This makes me twitchy. The dependencies should be better modelled, and idempotency used instead of logging and caching.
Even more painfully, I've been the maintenance programmer who was burned because some OTHER programmer trusted such a feature. And then it was my job to figure out the hidden assumption after it broke, long after the original programmer was gone. You know the old saying that you have to be twice as clever to debug code, as you need to be to write it? Debugging another person's clever and poorly commented tricks is no fun!
I'd therefore trust this feature a lot less than you appear to. I'd be tempted to instead wrap the existing loop with a new loop to which I can add instrumentation etc. It's more work. But if it breaks, it will be clear why it broke.
For example what happens if I use a different async backend like Tokio?
Swift for instance will explicitly make iterating on a dictionary not deterministic (by randomizing the iteration), in order to catch weird bugs early if a client relies (knowingly or not) on the specific order the elements of the dictionary are ordered.
I do seem to remember there was a claim regarding the fact that it also prevented a certain class of errors (that I mentioned earlier), but I cannot find the source again, so it might just be my memory playing tricks on me.
[1] https://forums.swift.org/t/psa-the-stdlib-now-uses-randomly-...
https://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-rev...
Yeah, great, my hello world program is deterministic.
What happens when you introduce I/O? Is every network call deterministic? Can you depend on reading a file taking the same amount of time and being woken up by the scheduler in the same order every time?
Coincidentally I have been experimenting with something very similar in JavaScript in the past and there the scheduler also has the same property.
Randomization is great at avoiding erroneous dependencies on spurious cause-and-effect chains. Determinism is needed to ensure the cause-and-effect chains that are core to the problem actually work.
