engine/tests/rabbitmq_queue_integration.rs (1)

1544-1545: ⚡ Quick win

Replace fixed sleeps before assertions with condition-based waits.

These sleep(Duration::from_secs(5)) calls can make CI flaky; wait until order.len() reaches the expected count with a timeout instead.

♻️ Proposed change

-    tokio::time::sleep(Duration::from_secs(5)).await;
+    tokio::time::timeout(Duration::from_secs(10), async {
+        loop {
+            if order.lock().await.len() == 6 {
+                break;
+            }
+            tokio::time::sleep(Duration::from_millis(25)).await;
+        }
+    })
+    .await
+    .expect("priority queue should drain all test messages");

-    tokio::time::sleep(Duration::from_secs(5)).await;
+    tokio::time::timeout(Duration::from_secs(10), async {
+        loop {
+            if order.lock().await.len() == 6 {
+                break;
+            }
+            tokio::time::sleep(Duration::from_millis(25)).await;
+        }
+    })
+    .await
+    .expect("subscriber priority queue should drain all test messages");

Also applies to: 1704-1705

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@engine/tests/rabbitmq_queue_integration.rs` around lines 1544 - 1545, Replace
the fixed tokio::time::sleep(Duration::from_secs(5)) calls throughout the test
with condition-based polling logic that waits until order.len() reaches the
expected count. Implement a loop with a timeout (using tokio::time::timeout or
similar) that continuously checks if the order vector has reached the desired
length, polling at small intervals rather than sleeping unconditionally. This
applies to the sleep calls at lines 1544-1545 and 1704-1705 (and any similar
instances), eliminating the flakiness caused by arbitrary fixed delays.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

engine/tests/rabbitmq_queue_integration.rs (1)

1544-1551: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Prefer polling the recorded order over a fixed drain sleep.

The deterministic gate makes ordering reliable, but the final sleep(Duration::from_secs(5)) is a fixed wait for the backlog to drain. On a slow CI runner this can be insufficient, so recorded may hold fewer than 6 entries and the assert_eq! fails with a misleading "wrong order" message rather than a timeout. Polling until 6 messages are recorded (with a timeout) makes the test both faster and more robust.

♻️ Poll for completion instead of a fixed sleep

-    tokio::time::sleep(Duration::from_secs(5)).await;
-
-    let recorded = order.lock().await;
+    tokio::time::timeout(Duration::from_secs(10), async {
+        loop {
+            if order.lock().await.len() == 6 {
+                break;
+            }
+            tokio::time::sleep(Duration::from_millis(50)).await;
+        }
+    })
+    .await
+    .expect("all 6 messages should drain");
+
+    let recorded = order.lock().await;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@engine/tests/rabbitmq_queue_integration.rs` around lines 1544 - 1551, Replace
the fixed tokio::time::sleep(Duration::from_secs(5)) with a polling loop that
repeatedly checks the recorded vector until it contains 6 entries, adding a
timeout guard to prevent infinite waits. This makes the test deterministic by
waiting for the actual completion condition (6 messages recorded) rather than a
fixed duration, which handles slow CI runners gracefully and provides clearer
failure messages if the condition is not met within the timeout.