Concurrent set execution sequencing in Zustand stores with async middleware

Answer

In Zustand v4.x, multiple set calls made synchronously (i.e., without awaiting) are processed in the exact order they appear. Each call triggers a shallow merge and immediately notifies subscribers before the next set begins. Async middleware such as persist does not reorder these state updates; it wraps the inner set, executes the merge synchronously, and then returns a promise that resolves after its asynchronous side‑effect (e.g., writing to storage) finishes in a later microtask. Therefore, the final store state reflects the synchronous call order, while any middleware side‑effects run after all synchronous sets have completed.

Confirmed facts

• Zustand processes store.set synchronously: shallow merge → subscriber notification → return.
• Subscriber listeners are invoked in the same order as the state updates that triggered them.
• Async middleware intercepts set, runs the inner set synchronously, then returns a promise resolved in a later microtask after its async work.
• If you await a set (i.e., the middleware returns a promise), the next set will only start after that promise resolves, so the order of state updates follows promise resolution order.

Likely explanation

The deterministic ordering for synchronous calls stems from Zustand’s implementation: the store’s set method is a plain function that updates the internal state and then iterates over subscribers. No internal queuing or reordering occurs. Async middleware adds a layer that defers its own work to the microtask queue, but it does not interfere with the synchronous state update pipeline. Consequently, side‑effects from middleware may observe a state that already includes later synchronous set calls.

Verification steps for this case

1. Create a store with persist middleware.
2. Add a logger inside the store’s set (or a subscriber) to capture the order of state updates.
3. Add a logger in the persist onStorageWrite callback to capture when the async side‑effect runs.
4. Call two set actions back‑to‑back without awaiting.
5. Observe that state logs appear in call order, while the storage log appears after both state logs.
6. Repeat the test with an await new Promise(r=>setTimeout(r,0)) between the two sets; notice the second state log appears after the delay, confirming promise‑resolution ordering.