fix: increase processWorkerQueueDebounceMs in priority test to prevent race condition

devin-ai-integration[bot] · ericallam · devin-ai-integration[bot] · commit 9579fbcb0765 · 2026-04-16T11:27:35.000Z
With PrismaPg adapter overhead, each trigger() call takes longer than with
the old Rust engine. A 50ms processWorkerQueueDebounceMs causes the background
processQueueForWorkerQueue job to fire between individual triggers, moving
items to the worker queue one-by-one in arrival (FIFO) order instead of
waiting for all items to be in the master queue and moving them collectively
in priority order.

Increase to 10s so the test's manual processMasterQueueForEnvironment call
controls the ordering.

Co-Authored-By: Eric Allam &lt;eallam@icloud.com&gt;
diff --git a/internal-packages/run-engine/src/engine/tests/priority.test.ts b/internal-packages/run-engine/src/engine/tests/priority.test.ts
@@ -27,7 +27,12 @@ describe("RunEngine priority", () => {
         },
         queue: {
           redis: redisOptions,
-          processWorkerQueueDebounceMs: 50,
+          // Use a large debounce so the background processQueueForWorkerQueue job
+          // doesn't race with the manual processMasterQueueForEnvironment call.
+          // With PrismaPg adapter overhead each trigger() takes longer, so a small
+          // debounce causes items to be moved to the worker queue individually in
+          // arrival order rather than collectively in priority order.
+          processWorkerQueueDebounceMs: 10_000,
           masterQueueConsumersDisabled: true,
         },
         runLock: {
