The key output order is 0 -> render count: 1. The handler closes over the state value from the current render.
A production symptom appears first: flaky tests, stale state, slow UI, late cleanup, or growing memory. This shows up in React forms, counters, analytics events, and logic that reads state immediately after updating it.
Expecting state variables to mutate immediately like plain objects.
Fix the root scheduling, cleanup, or concurrency pattern instead of adding arbitrary waits.
try {
await operation();
} finally {
cleanup();
}The console lane proves the visible order: 0 -> render count: 1. The active line and queues show why source order changed.
Reproduce the symptom with a small test, apply the safer pattern, then verify the flaky, slow, or leaking behavior disappears.
Related cases
Continue with nearby confusion while the mental model is fresh.
Effect cleanup race
This prevents wrong profile data, flickering search results, and stale route content in React apps.
Stale closure timeout
This affects delayed notifications, retry callbacks, telemetry, and timeout-based cleanup logic.
Fake timers vs promises
This is common in Jest/Vitest tests for debounced inputs, retries, loading spinners, and async React components.
Was this clear?
This stays local for now. It helps you track where the product still needs sharper cases.