April 3, 2026
Async drama: order… until chaos calls
Async Python Is Secretly Deterministic
Dev says Python async runs in order; commenters: “Sure… until the internet shows up”
TLDR: Author says Python’s async starts tasks in a fixed order, letting them tag steps for crash‑safe replays. Commenters clap back: it’s not guaranteed by the spec, other systems randomize, and real‑world I/O is messy—better to model dependencies and use safe‑to‑repeat actions instead.
A new post claims Python’s async is “secretly deterministic” because the event loop starts tasks in first‑come, first‑served order. The author tags each step before the first “await,” so crash‑recovery workflows can replay in a stable sequence. Translation: one‑lane road—cars enter in order; later traffic still weaves.
Comments exploded. Skeptics like lexicality quipped, “hello world is deterministic”—but real life isn’t: network calls wobble, file reads vary, timing goes feral. Standards hawks piled on: 12_throw_away warns asyncio does this now, but it’s an implementation detail; Trio even randomizes startup to prevent reliance. whinvik asked the buzzer question: is this guaranteed by the spec or just a lucky accident?
Pragmatists like jpollock felt “twitchy,” pushing dependency modeling and idempotency (safe repeats) over magical ordering. Fans exist too: arn3n adores repeatable runs for easier debugging. Vibe check: cool trick, fragile footing—and a meme: “Works on my machine… until Wi‑Fi.”
Key Points
- •Durable workflows require deterministic execution to support replay-based recovery.
- •Concurrency in async Python complicates step ordering due to variable interleavings.
- •In asyncio, newly created tasks are scheduled in FIFO order, providing a deterministic start sequence.
- •asyncio.gather enqueues tasks in the order provided, then the event loop begins them sequentially until each awaits.
- •Assigning step IDs before the first await (via a @Step decorator) yields a deterministic, replayable step order.