Race condition fixed in priority queue tests

matt-aitken

·Apr 24, 2026·#3440fix: disable RunQueue Worker in priority tests to prevent partial-batch race

Engine priority tests are now fully deterministic, eliminating a race condition where background worker jobs processed partial queue batches out of order.

Engine priority tests are now deterministic and reliable. Previously, a 50ms debounce window allowed background queue jobs to race against sequential test triggers, causing partial queue batches to process out of order. By explicitly disabling the background worker during these specific test runs, the system guarantees that batches process exactly as scheduled without interference. This removes a source of test flakiness in the engine package, providing cleaner and more accurate validation of queue priority logic.

View Original GitHub Description

Summary

The processMasterQueueForEnvironment call in the priority test was racing against background processQueueForWorkerQueue jobs scheduled 50ms after each trigger
With a 50ms debounce (processWorkerQueueDebounceMs: 50) and runs triggered sequentially, the RunQueue Worker could process those jobs mid-sequence, pushing partial batches to the worker queue in the wrong overall priority order
masterQueueConsumersDisabled: true only blocks the shard-level polling loops — it does not prevent the RunQueue's own Worker from processing these debounced jobs
Fix: add worker.disabled: true to the test 1 engine config, which propagates to workerOptions.disabled in the RunQueue constructor and prevents the Worker from starting

Test plan

Both priority tests pass: pnpm run test ./src/engine/tests/priority.test.ts --run
Test 1 log confirms no ✅ Starting run engine worker or worker loop messages — workers fully disabled
Test 2 unaffected (uses master queue consumers for automatic promotion, no disabled flag added)

🤖 Generated with Claude Code