Summary
The subscribeAsync stale-result prevention tests in packages/core/src/__tests__/context.test.ts (lines 261–299) rely on real promise microtask ordering rather than vi.useFakeTimers(). The test manually sequences focus pushes and manual promise resolutions, assuming a specific microtask ordering. Under scheduler pressure or if the internal debounce/scheduling changes, this ordering can silently reverse, causing the test to either pass with wrong assertions or flake intermittently.
Example
ctx.push({ widget: 'first' }, 'First panel');
ctx.push({ widget: 'second' }, 'Second panel');
await receivedSecond; // assumes 'second' completes before 'first'
resolveFirst?.({}); // then manually resolve pending first
await Promise.resolve(); // flush
await Promise.resolve();If subscribeAsync batches or debounces differently, receivedSecond could resolve after resolveFirst, reversing the expected ordering.
Fix
Use vi.useFakeTimers() + vi.runAllTimersAsync() to control scheduling explicitly, and assert stale results are dropped without depending on wall-clock microtask ordering.
Summary
The
subscribeAsyncstale-result prevention tests inpackages/core/src/__tests__/context.test.ts(lines 261–299) rely on real promise microtask ordering rather thanvi.useFakeTimers(). The test manually sequences focus pushes and manual promise resolutions, assuming a specific microtask ordering. Under scheduler pressure or if the internal debounce/scheduling changes, this ordering can silently reverse, causing the test to either pass with wrong assertions or flake intermittently.Example
If
subscribeAsyncbatches or debounces differently,receivedSecondcould resolve afterresolveFirst, reversing the expected ordering.Fix
Use
vi.useFakeTimers()+vi.runAllTimersAsync()to control scheduling explicitly, and assert stale results are dropped without depending on wall-clock microtask ordering.