Store subscriber limits: is reentrant dispatch during notification supported?

Answer to the Core Question

Yes. Redux core guarantees that calling store.dispatch() from within a store.subscribe listener is a supported, synchronous operation. The original notification loop pauses, the nested dispatch runs its own full cycle (reducer execution + subscriber notifications), and only after that does the outer loop resume.

How the Notification Loop Interleaves

1. Dispatch A is initiated.
2. The root reducer runs and updates state.
3. The store records the new state and starts notifying listeners in registration order.
4. Listener 1 runs. Inside it, it calls store.dispatch(B).
5. Dispatch B begins: its reducer runs, state is updated again, and all listeners are queued for a second notification cycle.
6. Listeners 1‑n for B run to completion. When B’s cycle ends, the state reference is stable again.
7. Control returns to Listener 1’s original call stack. The outer loop then continues with Listener 2, 3, …, all of which now see the state produced by Dispatch B.

Ordering Guarantees

• The order of listeners in each cycle is the order of subscribe registration.
• Nested cycles are fully isolated: they complete before the outer cycle proceeds.
• Listeners that have not yet been notified in the outer cycle will observe the state resulting from the nested dispatch.

Middleware Considerations

Redux Toolkit’s configureStore uses the same core createStore implementation, so the re‑entrant behaviour is identical. Middleware that is synchronous (e.g., thunk when used with immediate actions) participates in the same call stack. If a middleware performs asynchronous work (e.g., a saga that yields a promise), the nested dispatch occurs outside the current call stack and the outer notification loop may continue before the async side‑effect completes.

Practical Verification Steps

// Create a store
const store = createStore(reducer);

// Register listeners
store.subscribe(() => console.log('Listener A start', store.getState()));
store.subscribe(() => {
  console.log('Listener B start', store.getState());
  store.dispatch({type: 'INNER'});
});
store.subscribe(() => console.log('Listener C', store.getState()));

// Dispatch the outer action
store.dispatch({type: 'OUTER'});

Observe that the console logs show Listener B’s inner dispatch completing before Listener C runs, and Listener C sees the state after the inner dispatch.

When to Avoid Re‑entrancy

• Guard against infinite loops: a listener that always dispatches the same action can cause a stack overflow.
• Be cautious with heavy notification chains; each nested dispatch adds a full cycle of subscriber calls.
• Prefer explicit action flows where possible, but re‑entrancy is safe if used sparingly.

Conclusion

Re‑entrant dispatch is a deliberate part of Redux’s synchronous architecture. It preserves listener ordering, ensures state consistency, and behaves the same whether you use plain createStore or Redux Toolkit’s configureStore. Only asynchronous middleware can break the synchronous guarantee, which is a separate concern.