Stale derived values from non‑deterministic reactive block ordering

Question

Stale derived values from non‑deterministic reactive block ordering
Svelte compiles each reactive block ($:) into a dependency graph, executing them in source order by default. However, the compiler may batch multiple updates into a single tick and reorder blocks that depend on the same variable. This optimization is documented, but the order is not guaranteed when an async event triggers a state change, leading to intermittent stale derived values.
Because developers sometimes chain reactive assignments to derive state, the lack of determinism can result in a component rendering with an old value immediately after an asynchronous fetch and updating to the correct value on the next tick. This intermittent behaviour is hard to reproduce and can be mistaken for a race condition in the application code.
The documentation notes that developers should avoid relying on a specific order in such scenarios, yet there is no tooling to enforce it or to expose the actual execution sequence to the developer.

How can we determine the execution order of reactive blocks when multiple blocks depend on the same variable?
Does Svelte provide any flags or annotations to enforce a deterministic order?
What patterns can developers use to avoid relying on block ordering when designing derived state?

Tasadduq Burney · Answer

Determining and fixing stale derived values from non‑deterministic reactive block ordering
First, answer the question directly: you can observe the execution order by adding a unique console.log to each $: block, then trigger the asynchronous state change that causes the batch. The order printed in the console shows the compiler‑chosen sequence for that build. If you need a guaranteed order, Svelte 4 provides no flag or annotation to enforce it; the documented guidance is to avoid depending on block order. In Svelte 5, the $derived and $effect runes give a deterministic evaluation order, eliminating the stale‑value window.
Likely explanation
The likely cause is that Svelte 4 compiles each $: block into a node of a dependency graph. When two blocks read the same variable but neither writes a variable the other reads, the graph has no edge between them, so their relative order is unspecified. During a tick, Svelte may batch multiple synchronous mutations (e.g., from a Promise.then) and then execute the blocks in an implementation‑defined sequence, allowing a later block to see the pre‑update value of a shared dependency while an earlier block has already updated its derived state.
Confirmed facts

Svelte 4 creates a separate update function for each $: block; blocks are topologically sorted only by write‑read dependencies.
When blocks share only a read dependency, their order may change between builds or when the batcher groups updates.
Svelte 5 replaces $: with $state, $derived, and $effect; $derived values are memoized and evaluated in a single deterministic pass per tick, and $effect runs after all $derived updates.

Steps to diagnose order

Insert console.log('block A') in the first $: block and console.log('block B') in the second.
Modify the shared variable inside a Promise.resolve().then(() => { … }) callback so the change is batched.
Run the component, open the console, and note the log sequence.
Re‑build the project (or add an unrelated state change) and repeat; a different sequence indicates non‑determinism.

Patterns to avoid reliance on block ordering

Combine related derivations into a single $: block so there is only one node for that logic.
Use a writable store with a derived store (derived(store, fn)) – the store graph enforces a single evaluation order.
In Svelte 5, migrate to $derived for pure computed values and $effect for side‑effects; this guarantees that effects see up‑to‑date derived values.
Avoid placing side‑effects that depend on a variable in one block and mutating that variable in another block that shares only a read dependency.

To give a definitive recommendation, please confirm whether you are using Svelte 4 or Svelte 5.

Stale derived values from non‑deterministic reactive block ordering