crates/p2p/src/tests/util.rs (1)

1146-1152: ⚠️ Potential issue | 🟡 Minor

Enforce timeout before evaluating check() in poll_until.

Line 1148 runs check() before the deadline guard, so a late success can slip through after timeout.

Suggested fix

 pub(crate) async fn poll_until(
     timeout: Duration,
     msg: &str,
     check: impl Fn() -> bool,
 ) -> eyre::Result<()> {
     let deadline = tokio::time::Instant::now() + timeout;
     loop {
+        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         if check() {
             return Ok(());
         }
-        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         tokio::time::sleep(Duration::from_millis(100)).await;
     }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/util.rs` around lines 1146 - 1152, The timeout guard in
poll_until currently calls the closure check() before verifying the deadline,
allowing a late success to bypass the timeout; change the loop so you check the
deadline first (using the existing deadline variable and eyre::ensure! with the
same {msg}) and only call check() after the deadline check, then await the sleep
if not ready—this ensures the timeout is enforced before evaluating check()
while keeping the existing deadline, msg, and sleep(Duration::from_millis(100)).

crates/p2p/src/tests/integration/mod.rs (1)

224-225: ⚠️ Potential issue | 🟡 Minor

Replace the remaining fixed sleeps in negative-path tests.

Line 225 and Line 325 still rely on hard timing delays, so these paths remain timing-sensitive and can flake under load variance.

Also applies to: 323-325

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/integration/mod.rs` around lines 224 - 225, The
remaining fixed sleeps (tokio::time::sleep(Duration::from_millis(200)).await) in
the negative-path integration tests make them timing-sensitive; replace them
with event-driven waits by awaiting a deterministic signal or condition (e.g., a
oneshot/watch channel, a join handle, or polling a shared state) or wrap the
wait in tokio::time::timeout to fail fast if the expected error/event doesn't
occur; update the tests that currently call tokio::time::sleep(...) to instead
wait for the gossip client to emit the expected failure event or for a oneshot
receiver to be triggered so the test no longer depends on a hard-coded delay.

crates/p2p/src/tests/util.rs (1)

1146-1152: ⚠️ Potential issue | 🟡 Minor

Enforce timeout before running check().

poll_until currently allows a pass after the deadline because timeout is checked after check() (Line 1148 vs. Line 1151).

Suggested fix

 pub(crate) async fn poll_until(
     timeout: Duration,
     msg: &str,
     check: impl Fn() -> bool,
 ) -> eyre::Result<()> {
     let deadline = tokio::time::Instant::now() + timeout;
     loop {
+        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         if check() {
             return Ok(());
         }
-        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         tokio::time::sleep(Duration::from_millis(100)).await;
     }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/util.rs` around lines 1146 - 1152, The timeout check is
performed after calling check(), allowing a final check to run past the
deadline; in the poll_until loop move the deadline enforcement to the top of the
loop (or perform eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}")
before calling check()) so the function (poll_until) verifies the deadline
before each invocation of check(); keep the
sleep(Duration::from_millis(100)).await and return Ok(()) when check() is true.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (1)

2515-2529: ⚠️ Potential issue | 🟠 Major

Follow-up: spiky_ still gets dropped during rename reconstruction.

This is the same prefix-rebuild path as the earlier non-resource-prefix fix, but spiky_ now carries test-group = 'spiky' semantics while also looking like a 1T class. For names like spiky_heavy4_*, classes_to_prefix() keeps only the highest thread tier and classification_to_prefix() does not preserve spiky, so apply can silently strip the spiky group assignment on any rename.

Also applies to: 2554-2560

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 2515 -
2529, The current thread-prefix selection in classes_to_prefix() (the
all_classes search and thread_parts truncation logic that uses
thread_parts.sort_by(...); thread_parts.truncate(1)) drops non-thread group
prefixes like "spiky_" when reconstructing renames; change the logic to preserve
any non-thread group token present on the original name: when you push into
thread_parts include the original name/token (e.g., push (threads,
name.as_str(), name_token) or mark that the name carried a non-thread group),
select the highest thread tier as before but also carry-forward the original
non-thread group token into the returned prefix list so
classification_to_prefix() and apply() can emit both the group prefix (e.g.,
"spiky") and the thread tier (e.g., "heavy4") instead of stripping the group;
update classification_to_prefix()/apply to accept and concatenate both group and
thread components when present.

crates/chain-tests/src/validation/poa_cases.rs (1)

19-23: ⚠️ Potential issue | 🟡 Minor

Use tracing-aware test attribute for this async test.

Since this test initializes tracing and logs, switch #[tokio::test] to #[test_log::test(tokio::test)] on Line 19.

Suggested patch

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn multi_slot_poa_test() -> eyre::Result<()> {

As per coding guidelines: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/poa_cases.rs` around lines 19 - 23, Replace
the test attribute on the async test multi_slot_poa_test: change the current
#[tokio::test] on the multi_slot_poa_test function to the tracing-aware
attribute #[test_log::test(tokio::test)] so tracing initialized by
initialize_tracing() is captured by the test harness; update only the attribute
above fn multi_slot_poa_test() accordingly.

crates/chain-tests/src/multi_node/fork_recovery_epoch.rs (1)

233-235: ⚠️ Potential issue | 🟠 Major

Wait for canonical hash convergence, not only height.

Line 234 only guarantees the node reached height 5; it does not guarantee canonical height-5 has switched to peer2_hash. This can race and make the assertion flaky.

🔧 Proposed fix

-    // wait_until_height polls until the node reaches the expected height
-    let genesis_hash = genesis_node.wait_until_height(5, seconds_to_wait).await?;
-    let genesis_head = genesis_node.get_block_by_hash(&genesis_hash)?;
+    // First ensure height is reached, then wait for canonical height-5 hash to converge to peer2.
+    genesis_node.wait_until_height(5, seconds_to_wait).await?;
+    let start = Instant::now();
+    let timeout = Duration::from_secs(seconds_to_wait as u64);
+    let genesis_head = loop {
+        let candidate = genesis_node.get_block_by_height(5).await?;
+        if candidate.block_hash == peer2_hash {
+            break candidate;
+        }
+        if start.elapsed() > timeout {
+            panic!(
+                "Timeout waiting for canonical height-5 to switch to peer2 hash. expected={}, got={}",
+                peer2_hash, candidate.block_hash
+            );
+        }
+        tokio::time::sleep(Duration::from_millis(50)).await;
+    };
+    let genesis_hash = genesis_head.block_hash;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/multi_node/fork_recovery_epoch.rs` around lines 233 -
235, The test currently only waits for height via
genesis_node.wait_until_height(5, seconds_to_wait) and then reads a single block
(genesis_hash/genesis_head), which can race if the canonical height-5 block
hasn't switched to peer2_hash; change the logic to poll until the canonical
block at height 5 equals peer2_hash (or until timeout seconds_to_wait): after
calling wait_until_height, repeatedly fetch the canonical block at height 5 (or
fetch the head and compare its hash) using the node RPC helpers you already have
(e.g., calls around genesis_node.get_block_by_hash / get_block_by_height or
reading the head) and break only when the returned hash equals peer2_hash,
otherwise retry until seconds_to_wait expires and fail with a clear assertion if
it never converges.

crates/chain-tests/src/api/tx_commitments.rs (1)

342-343: ⚠️ Potential issue | 🟡 Minor

Use #[test_log::test(tokio::test)] for this tracing-heavy async test.

This test uses tracing output (debug_span!, debug!) but is annotated with #[tokio::test]. As per coding guidelines, tests requiring tracing output should use #[test_log::test(tokio::test)].

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn heavy_no_commitments_basic_test() -> eyre::Result<()> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/tx_commitments.rs` around lines 342 - 343, The
test heavy_no_commitments_basic_test is using tracing (debug_span!, debug!) but
is annotated with #[tokio::test]; change its attribute to use the test_log
wrapper so tracing is captured by replacing #[tokio::test] with
#[test_log::test(tokio::test)] on the heavy_no_commitments_basic_test async
function (ensure the attribute is updated exactly on that function declaration).

crates/chain-tests/src/api/hardfork_tests.rs (1)

328-328: ⚠️ Potential issue | 🟠 Major

Restore tier-prefixed names for nextest classification.

At Line 328 and Line 630, renaming heavy_test_* to test_* can bypass regex-based nextest tier overrides and silently change timeout/resource behavior.

Suggested patch

-    async fn test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
+    async fn heavy_test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
...
-    async fn test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {
+    async fn heavy_test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {

Also applies to: 630-630

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/hardfork_tests.rs` at line 328, The test functions
that were renamed from heavy_test_* to test_* (including the function currently
named test_boundary_crossing_v1_behavior) must keep their heavy_test_* prefixes
so nextest's regex-based tier overrides still apply; restore the original
heavy_test_* names for the affected functions (the one at the start of
test_boundary_crossing_v1_behavior and the other renamed at the second
occurrence around the other reported spot) so timeouts/resources are preserved
and rerun the tests.

crates/chain-tests/src/validation/unstake_edge_cases.rs (1)

194-194: ⚠️ Potential issue | 🟠 Major

Keep heavy_ prefix for nextest resource tiering.

Renaming this test to block_unstake_never_staked_gets_rejected may drop it out of heavy-tier scheduling and change concurrency/resources unexpectedly. Please keep it as heavy_block_unstake_never_staked_gets_rejected (or adjust nextest filters accordingly).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/unstake_edge_cases.rs` at line 194, The
test function was renamed and lost the heavy_ prefix which affects nextest
resource tiering; restore the original name
heavy_block_unstake_never_staked_gets_rejected (revert the signature async fn
block_unstake_never_staked_gets_rejected() -> eyre::Result<()> back to async fn
heavy_block_unstake_never_staked_gets_rejected() -> eyre::Result<()>) so it
remains in the heavy tier, or if you intentionally want to change tiers, update
the nextest filters/config instead; refer to the test function name
heavy_block_unstake_never_staked_gets_rejected when making the change.

crates/chain-tests/src/synchronization/mod.rs (1)

273-276: 🧹 Nitpick | 🔵 Trivial

Derive peer wait attempts from max_seconds instead of hardcoding 100.

The hardcoded 100 attempts doesn't align with the test's max_seconds variable used elsewhere. If wait_until_sees_peer polls at a fixed interval, the attempt count should be derived consistently.

Proposed refactor

     // Wait for peer to connect
+    // wait_until_sees_peer polls at ~100ms intervals
+    let peer_wait_attempts = (max_seconds * 10) as usize;
     genesis_node
-        .wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(), 100)
+        .wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(), peer_wait_attempts)
         .await?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/synchronization/mod.rs` around lines 273 - 276,
Replace the hardcoded 100 attempts passed to
genesis_node.wait_until_sees_peer(...) with a value derived from the test's
max_seconds (e.g., let attempts = max_seconds / POLL_INTERVAL_SECONDS) so the
retry count matches the overall timeout; if there isn't an existing poll
interval constant, introduce a POLL_INTERVAL_SECONDS (or POLL_INTERVAL_MS and
convert) near the synchronization test helpers, compute attempts using that
constant, and pass the computed attempts to
wait_until_sees_peer(peer.node_ctx.config.node_config.peer_address(), attempts).

crates/utils/nextest-monitor/src/bin/nextest-report.rs (1)

680-701: ⚠️ Potential issue | 🟠 Major

Long and mid-duration I/O tests still marked as safe to apply.

The past review flagged that branches emitting "verify contention sensitivity" messages should set safe_to_apply = false. Looking at lines 680-701, the long I/O and mid I/O branches still have safe_to_apply defaulting to true (set at line 579), despite their messages requiring manual verification. Only the spike-justified branch (line 662) explicitly sets safe_to_apply = false.

Proposed fix

                 } else if duration >= LONG_TEST_DURATION_MS {
+                    safe_to_apply = false;
                     // Long I/O test: biggest performance opportunity, but also
                     // most sensitive to contention
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — long-running I/O test, wastes {:.0}s thread-time. High perf impact, but verify contention sensitivity",
                         test.avg_avg_cpu.unwrap_or(0.0),
                         peak_cpu,
                         current.effective_threads,
                         format_duration(duration),
                         wasted_thread_secs,
                     ));
                 } else {
+                    safe_to_apply = false;
                     // Medium-duration I/O test
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — I/O-bound, {:.0}s thread-time wasted. Verify contention sensitivity before downgrading",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 680 -
701, The long-duration and medium-duration I/O branches still leave
safe_to_apply true but their messages require manual verification; update the
branches that handle duration >= LONG_TEST_DURATION_MS and the else
(medium-duration) branch to set safe_to_apply = false (the same variable
currently defaulted earlier) before pushing the issues (the blocks that call
issues.push with the "verify contention sensitivity" messages).

crates/chain-tests/src/startup/genesis.rs (1)

12-14: ⚠️ Potential issue | 🟡 Minor

Use #[test_log::test(tokio::test)] for this tracing-enabled async test.

This test explicitly initializes tracing, so it should use the test_log macro instead of plain #[tokio::test] to match repo test conventions.

Proposed fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn test_genesis_state_dump_and_restore() -> eyre::Result<()> {
-    initialize_tracing();
+    initialize_tracing();

As per coding guidelines: Use #[test_log::test(tokio::test)] for tests that require tracing output.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/startup/genesis.rs` around lines 12 - 14, The test
function test_genesis_state_dump_and_restore is using #[tokio::test] but
initializes tracing; replace the attribute with #[test_log::test(tokio::test)]
so the tracing output is captured by the repo's test harness; update the
function's annotation only (leave initialize_tracing() and the async signature
unchanged).

crates/chain-tests/src/validation/poa_cases.rs (1)

19-23: ⚠️ Potential issue | 🟡 Minor

Use #[test_log::test(tokio::test)] for this tracing-enabled test.

This test initializes tracing via initialize_tracing() and logs with info!() at lines 73 and 92. Per coding guidelines, tests that require tracing output should use the tracing-aware test attribute.

🔧 Apply the correct test attribute

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn multi_slot_poa_test() -> eyre::Result<()> {

As per coding guidelines: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/poa_cases.rs` around lines 19 - 23, Replace
the current #[tokio::test] on the multi_slot_poa_test function with the
tracing-aware attribute #[test_log::test(tokio::test)] and remove the manual
tracing setup (the unsafe std::env::set_var("RUST_LOG", "info") call and the
initialize_tracing() invocation) so the test uses the test_log harness for
tracing; update references in the multi_slot_poa_test function accordingly.

crates/chain-tests/src/api/hardfork_tests.rs (1)

328-328: ⚠️ Potential issue | 🟠 Major

Restore tier-prefixed names to preserve nextest scheduling behavior.

At Line 328 and Line 630, renaming to test_* can drop these tests out of regex-based nextest tier groups (heavy/slow/spiky), which changes timeout/resource settings and can reintroduce CI flakiness.

Suggested patch

-    async fn test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
+    async fn heavy_test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
...
-    async fn test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {
+    async fn heavy_test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {

Also applies to: 630-630

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/hardfork_tests.rs` at line 328, The test function
name was changed to test_boundary_crossing_v1_behavior which breaks nextest
regex-based tier grouping and alters CI scheduling; restore the original
tier-prefixed test name (the prior heavy_/slow_/spiky_ prefix used for this
test) for this function and the other renamed test at the other location so they
match the nextest tier patterns, and update any references (function calls,
attributes) accordingly to preserve the original CI timeouts/resource grouping.

crates/chain-tests/src/multi_node/validation.rs (1)

317-322: ⚠️ Potential issue | 🟡 Minor

Remove the stale heavy3_ scheduler note.

The function has been renamed to heavy_block_shadow_txs_different_order_of_txs, so this comment now advertises the wrong CI class and can mislead future reclassification work.

Suggested fix

-// "heavy3_" prefix: requires 3 CI threads (see .config/nextest.toml)
 #[test_log::test(tokio::test)]
 async fn heavy_block_shadow_txs_different_order_of_txs() -> eyre::Result<()> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/multi_node/validation.rs` around lines 317 - 322,
Remove the stale "heavy3_" scheduler note from the test comment above the
heavy_block_shadow_txs_different_order_of_txs function; update or delete the
line that mentions "heavy3_" so the comment no longer advertises the wrong CI
class and does not mislead future reclassification work, ensuring the comment
reflects the current function name and intended CI classification.

crates/chain-tests/src/api/tx_commitments.rs (1)

342-343: ⚠️ Potential issue | 🟡 Minor

Use test_log for this tracing-heavy async test.

This test still initializes tracing and emits debug_span!/debug!, but the harness is plain #[tokio::test], so failures here won't get the same captured tracing as the other renamed tests.

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn heavy_no_commitments_basic_test() -> eyre::Result<()> {

As per coding guidelines, "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/tx_commitments.rs` around lines 342 - 343, The
async test heavy_no_commitments_basic_test is using plain #[tokio::test] but
emits tracing (debug_span!/debug!), so replace its attribute with the test_log
wrapper to capture logs; change the test annotation to use
#[test_log::test(tokio::test)] on the heavy_no_commitments_basic_test function
to ensure tracing output is captured by the test harness.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (2)

680-701: ⚠️ Potential issue | 🟠 Major

Don't auto-apply downgrades that still require manual verification.

These long-/mid-I/O branches say "verify contention sensitivity" but never flip safe_to_apply, so cmd_apply() will still rename exactly the cases analyze presents as manual-review decisions.

Suggested fix

                 } else if duration >= LONG_TEST_DURATION_MS {
+                    safe_to_apply = false;
                     // Long I/O test: biggest performance opportunity, but also
                     // most sensitive to contention
                     issues.push(format!(
@@
                 } else {
+                    safe_to_apply = false;
                     // Medium-duration I/O test
                     issues.push(format!(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 680 -
701, The report generation marks long-/mid-duration I/O cases as "verify
contention sensitivity" but never clears the safe_to_apply flag, allowing
cmd_apply() to auto-rename tests that should require manual review; update the
branches that build the issues for the LONG_TEST_DURATION_MS and the
medium-duration else branch (the block that pushes strings like "verify
contention sensitivity" / "Verify contention sensitivity before downgrading") to
also set safe_to_apply = false (the same variable checked by cmd_apply())
whenever those messages are emitted so these cases are not auto-applied.

---

2708-2738: ⚠️ Potential issue | 🟡 Minor

Ignore commented-out fn lines when resolving rename targets.

A line like // pub async fn old_name() still passes the current before_fn.ends_with("pub async ") check, so find_function_def() can select the comment line and apply will rewrite the comment instead of the real test definition.

Suggested fix

         for (line_idx, line) in content.lines().enumerate() {
             let trimmed = line.trim();
-            if trimmed.contains(&pattern) {
+            if let Some(match_start) = line.find(&pattern) {
+                if line[..match_start].rfind("//").is_some() {
+                    continue;
+                }
                 // Verify it's actually a function definition, not just a comment or string
                 let before_fn = trimmed.split("fn ").next().unwrap_or("");
                 // Should be empty, start with pub/async/unsafe, or be a #[test] etc.
                 if before_fn.is_empty()
                     || before_fn.ends_with("pub ")
@@
-                    let after_name_start = trimmed.find(&pattern).unwrap() + pattern.len();
+                    let after_name_start = trimmed.find(&pattern).unwrap() + pattern.len();
                     if let Some(ch) = trimmed[after_name_start..].chars().next() {
                         if ch == '(' || ch == '<' || ch == ' ' {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 2708 -
2738, The loop in find_function_def() can pick up commented-out definitions
because it only checks trimmed.contains(&pattern); update the loop to skip
commented lines before further checks by rejecting lines where
trimmed.starts_with("//") or trimmed.starts_with("/*") (and optionally lines
where the "fn" occurs after a "//" comment marker), so that before_fn/trimmed
logic only runs on non-comment code lines; keep the rest of the logic (using
pattern, before_fn, after_name_start, hint_segments, and pushing to candidates)
unchanged.

crates/chain-tests/src/block_production/treasury_tracking.rs (1)

11-12: ⚠️ Potential issue | 🟡 Minor

Switch this tracing test to #[test_log::test(tokio::test)].

test_treasury_tracking initializes tracing and logs, so plain #[tokio::test] is inconsistent with repo test logging standards.

♻️ Proposed fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn test_treasury_tracking() -> eyre::Result<()> {

As per coding guidelines "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/block_production/treasury_tracking.rs` around lines 11
- 12, Replace the test attribute on test_treasury_tracking so it uses the
repository's tracing-enabled test macro: change the current #[tokio::test]
annotation on the async function test_treasury_tracking() to
#[test_log::test(tokio::test)] so tracing/log initialization in that test
follows the project's logging standards.

crates/chain-tests/src/promotion/promotion_with_multiple_proofs.rs (1)

7-8: ⚠️ Potential issue | 🟡 Minor

Use test_log wrapper for this tracing-enabled async test.

This test configures tracing (RUST_LOG + initialize_tracing) but still uses #[tokio::test].

♻️ Proposed fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn spiky_heavy4_promotion_with_multiple_proofs_test() -> eyre::Result<()> {

As per coding guidelines "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/promotion/promotion_with_multiple_proofs.rs` around
lines 7 - 8, The test function spiky_heavy4_promotion_with_multiple_proofs_test
is using #[tokio::test] but needs the test_log wrapper to capture tracing
output; change the attribute from #[tokio::test] to
#[test_log::test(tokio::test)] on the
spiky_heavy4_promotion_with_multiple_proofs_test function so tracing (RUST_LOG +
initialize_tracing) is properly captured during the async test while leaving the
async signature and body unchanged.

crates/chain-tests/src/synchronization/mod.rs (1)

273-276: 🧹 Nitpick | 🔵 Trivial

Avoid hardcoded peer wait attempts.

Using literal 100 decouples this wait from max_seconds; derive attempts from the existing timeout budget to keep timing behavior consistent.

♻️ Proposed refactor

-    genesis_node
-        .wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(), 100)
-        .await?;
+    let peer_wait_attempts = (max_seconds * 10) as usize; // 100ms polling
+    genesis_node
+        .wait_until_sees_peer(
+            &peer.node_ctx.config.node_config.peer_address(),
+            peer_wait_attempts,
+        )
+        .await?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/synchronization/mod.rs` around lines 273 - 276,
Replace the hardcoded retry count 100 passed to
genesis_node.wait_until_sees_peer(...) with a value derived from the existing
timeout budget (use the test's max_seconds timeout variable or compute attempts
from it) so the peer-waiting behavior tracks the same timeout; update the call
site
(genesis_node.wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(),
...).await?) to use the derived attempts variable instead of the literal 100.

crates/p2p/src/tests/block_pool/mod.rs (1)

550-560: ⚠️ Potential issue | 🟠 Major

is_block_processing is not a reliable completion barrier here.

This loop can exit before async parent-fetch/recovery work is actually exercised, so downstream assertions can still race and flap.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/block_pool/mod.rs` around lines 550 - 560, The loop uses
is_block_processing(&block3.block_hash) which can return false before the async
parent-fetch/recovery work has actually run, causing racey tests; change the
test to wait on an explicit completion condition for block3’s recovery instead
of just is_block_processing—either call a dedicated test helper on block_pool
(e.g., await_block_processed / wait_for_recovery) that returns only after
parent-fetch/recovery finished, or poll a deterministic observable state (e.g.,
block_pool.block_state(&block3.block_hash) reaching the expected
Failed/Recovered state or a recorded parent-fetch-attempt flag) so the test only
proceeds once the parent-fetch path has been exercised. Ensure you reference
is_block_processing, block_pool, and block3.block_hash when adding or using the
new wait condition.

crates/p2p/src/tests/util.rs (1)

1146-1152: ⚠️ Potential issue | 🟡 Minor

Enforce the deadline before evaluating check().

poll_until() can still return success slightly after timeout because it calls check() before comparing Instant::now() to deadline.

🔧 Suggested fix

 pub(crate) async fn poll_until(
     timeout: Duration,
     msg: &str,
     check: impl Fn() -> bool,
 ) -> eyre::Result<()> {
     let deadline = tokio::time::Instant::now() + timeout;
     loop {
+        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         if check() {
             return Ok(());
         }
-        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         tokio::time::sleep(Duration::from_millis(100)).await;
     }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/util.rs` around lines 1146 - 1152, The loop in
poll_until currently calls check() before verifying the deadline, allowing a
success after timeout; update the loop in poll_until so you first compare
tokio::time::Instant::now() < deadline (using eyre::ensure! to fail if past
deadline) and only then call check(), returning Ok(()) if true; keep the
existing sleep(Duration::from_millis(100)).await between iterations so the
deadline check runs before each evaluation of check().

crates/chain-tests/src/utils.rs (1)

2865-2886: 🧹 Nitpick | 🔵 Trivial

Add slow-path diagnostics to this waiter.

This helper is now on the async chunk-migration path, but unlike the neighboring waiters it does not emit diag_wait_state() when it stalls, which makes CI failures here much harder to debug.

🔧 Suggested fix

+    #[diag_slow(state = format!(
+        "ledger={:?} chunk_offset={} {}",
+        ledger,
+        u64::from(chunk_offset),
+        self.diag_wait_state().await
+    ))]
     pub async fn wait_for_chunk_in_storage(
         &self,
         ledger: DataLedger,
         chunk_offset: LedgerChunkOffset,
         max_seconds: usize,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/utils.rs` around lines 2865 - 2886, The waiter
wait_for_chunk_in_storage currently polls without emitting diagnostics when it
stalls; add calls to the existing diag_wait_state method to mirror neighboring
waiters: invoke self.diag_wait_state(...) periodically during the loop (e.g.,
every 10 attempts or when attempt * 1s crosses a stall threshold) including
identifying context ("wait_for_chunk_in_storage", ledger, chunk_offset, attempt,
max_seconds), and call diag_wait_state once more just before returning the Err
so test logs contain the ledger and chunk_offset for debugging.

.config/nextest.toml (1)

24-24: ⚠️ Potential issue | 🟠 Major

Compound include/exclude filters are still risky for nextest-report classification parsing.

These ... - test(/.*spiky_.*/) expressions match the previously reported parser gap in extract_test_pattern() for non-single-clause filters. If unresolved, analyze/apply/schedule can misclassify or ignore config-derived rules.

#!/bin/bash
set -euo pipefail

# Inspect parser behavior and current compound filters.
rg -n -C20 'fn extract_test_pattern|from_nextest_toml|test\\(' crates/utils/nextest-monitor/src/bin/nextest-report.rs
rg -n -C1 " - test\\(/\\.\\*spiky_\\.\\*/\\)" .config/nextest.toml

Also applies to: 30-30, 36-36, 42-42

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.config/nextest.toml at line 24, The compound filter using subtraction
("filter = 'test(/.*slow_.*/) - test(/.*spiky_.*/)'") cannot be reliably parsed
by extract_test_pattern/from_nextest_toml; split the clause into separate,
single-clause include and exclude filters so the parser sees only simple clauses
(e.g. set filter = "test(/.*slow_.*/)" and add an exclude = "test(/.*spiky_.*/)"
or supply two distinct filter entries), and update any other similar compound
filters in the file so extract_test_pattern only receives single-clause
patterns.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (2)

680-700: ⚠️ Potential issue | 🟠 Major

Don't auto-apply downgrades that the report already marks for manual verification.

These branches still tell the operator to verify contention sensitivity, but safe_to_apply remains true, so cmd_apply() will rename them anyway.

Suggested fix

                 } else if duration >= LONG_TEST_DURATION_MS {
+                    safe_to_apply = false;
                     // Long I/O test: biggest performance opportunity, but also
                     // most sensitive to contention
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — long-running I/O test, wastes {:.0}s thread-time. High perf impact, but verify contention sensitivity",
@@
                 } else {
+                    safe_to_apply = false;
                     // Medium-duration I/O test
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — I/O-bound, {:.0}s thread-time wasted. Verify contention sensitivity before downgrading",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 680 -
700, The report is adding issues that require manual verification but leaving
safe_to_apply true so cmd_apply() will still auto-rename; update the logic in
the branches that push the "verify contention sensitivity" messages (the
LONG_TEST_DURATION_MS branch and the medium-duration I/O branch that call
issues.push(...)) to also set safe_to_apply = false for that test (the same
scope where test, current, duration, wasted_thread_secs are available) so tests
requiring manual verification are not auto-applied by cmd_apply().

---

2712-2742: ⚠️ Potential issue | 🟡 Minor

Definition lookup still accepts commented-out async fn lines.

The trimmed.contains(&pattern) + before_fn.ends_with("async ") check will accept lines like // async fn old_name(). If that comment appears before the real definition, cmd_apply() rewrites the comment and leaves the function unchanged.

Suggested fix

         for (line_idx, line) in content.lines().enumerate() {
-            let trimmed = line.trim();
-            if trimmed.contains(&pattern) {
+            if let Some(match_start) = line.find(&pattern) {
+                if line[..match_start].rfind("//").is_some() {
+                    continue;
+                }
                 // Verify it's actually a function definition, not just a comment or string
-                let before_fn = trimmed.split("fn ").next().unwrap_or("");
+                let before_fn = line[..match_start].trim_start();
@@
-                    let after_name_start = trimmed.find(&pattern).unwrap() + pattern.len();
-                    if let Some(ch) = trimmed[after_name_start..].chars().next() {
+                    let after_name_start = match_start + pattern.len();
+                    if let Some(ch) = line[after_name_start..].chars().next() {

.config/nextest.toml (1)

28-42: ⚠️ Potential issue | 🟠 Major

These exclude filters still break nextest-report config loading.

crates/utils/nextest-monitor/src/bin/nextest-report.rs::extract_test_pattern() still only understands a single test(...) clause. With filters like test(/.*heavy_.*/) - test(/.*spiky_.*/), ClassificationConfig::from_nextest_toml() builds an invalid regex and falls back to default_config(), so analyze, schedule, and apply stop honoring the overrides in this file.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.config/nextest.toml around lines 28 - 42, The filter parser
extract_test_pattern() currently only captures a single test(...) clause, so
filters like "test(/.*heavy_.*/) - test(/.*spiky_.*/)" produce invalid regexes;
update extract_test_pattern to find all test(...) occurrences in the filter
string, ignore those that are exclusion clauses (preceded by a '-' token), and
combine the remaining positive test(...) patterns into a single alternation
regex (e.g. join with | and wrap in (?:...)). Ensure
ClassificationConfig::from_nextest_toml() uses this updated extract_test_pattern
behavior so overrides with multiple clauses or subtractions are parsed correctly
and do not fall back to default_config().

crates/chain-tests/src/validation/unstake_edge_cases.rs (1)

194-194: ⚠️ Potential issue | 🔴 Critical

Restore heavy_ prefix to preserve nextest resource tiering.

Renaming this to block_unstake_never_staked_gets_rejected likely drops it out of the heavy_* scheduling bucket, which can under-provision the test and increase flakiness under parallel load. Please rename back to heavy_block_unstake_never_staked_gets_rejected if the heavy-name filter is still active in .config/nextest.toml.

#!/bin/bash
set -euo pipefail

echo "== Confirm current nextest heavy filter =="
rg -n -C3 'heavy_\*|heavy_|threads-required|filter' .config/nextest.toml

echo
echo "== Confirm this test name in current file =="
rg -n -C2 'unstake_never_staked_gets_rejected|heavy_block_unstake_never_staked_gets_rejected' crates/chain-tests/src/validation/unstake_edge_cases.rs

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/unstake_edge_cases.rs` at line 194, Restore
the original heavy_ prefix on the test function by renaming
block_unstake_never_staked_gets_rejected back to
heavy_block_unstake_never_staked_gets_rejected so it remains matched by the
nextest heavy filter; update the function declaration name (async fn
heavy_block_unstake_never_staked_gets_rejected()) and any internal references or
calls to that symbol, and ensure the test still compiles and runs under the
existing .config/nextest.toml heavy_* filter.

crates/chain-tests/src/api/tx_commitments.rs (1)

342-343: ⚠️ Potential issue | 🟡 Minor

Use #[test_log::test(tokio::test)] for this tracing-heavy async test.

This test uses tracing output (debug_span! at line 353, debug! at line 355) but is annotated with #[tokio::test]. As per coding guidelines, tests that require tracing output should use #[test_log::test(tokio::test)].

📝 Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn heavy_no_commitments_basic_test() -> eyre::Result<()> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/tx_commitments.rs` around lines 342 - 343, The
async test heavy_no_commitments_basic_test is using tracing (debug_span!,
debug!) but is annotated with #[tokio::test]; change its attribute to
#[test_log::test(tokio::test)] so tracing output is captured during test runs —
update the annotation above the heavy_no_commitments_basic_test function to use
test_log::test with tokio::test.

crates/chain-tests/src/validation/ingress_proof_validation.rs (1)

369-369: 🧹 Nitpick | 🔵 Trivial

Inconsistent test naming: heavy_ prefix retained.

The first two tests (lines 24 and 171) had their heavy prefix completely removed, but this test retains it. The test at line 171 involves multiple epoch transitions and appears more resource-intensive, yet has no heavy prefix. For consistency with the other renamed tests in this file, consider removing the heavy_ prefix entirely.

♻️ Suggested rename for consistency

-async fn heavy_mempool_rejects_unstaked_but_accepts_pending_stake_ingress_proofs(
+async fn mempool_rejects_unstaked_but_accepts_pending_stake_ingress_proofs(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/ingress_proof_validation.rs` at line 369,
Rename the test function
heavy_mempool_rejects_unstaked_but_accepts_pending_stake_ingress_proofs to
remove the heavy_ prefix so its name matches the other renamed tests (e.g.,
mempool_rejects_unstaked_but_accepts_pending_stake_ingress_proofs); update the
function identifier and any references to it (test attributes or calls) to use
the new name to keep naming consistent across the file.

crates/chain-tests/src/validation/poa_cases.rs (1)

19-20: ⚠️ Potential issue | 🟡 Minor

Use tracing-aware test attribute here.

This tracing-enabled async test still uses #[tokio::test] instead of the tracing wrapper.

Suggested patch

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn multi_slot_poa_test() -> eyre::Result<()> {

#!/bin/bash
set -euo pipefail

# Verify this test initializes tracing / emits tracing logs while using tokio::test.
rg -n -C3 'tokio::test|test_log::test|initialize_tracing\(|tracing::info!|info!\(' crates/chain-tests/src/validation/poa_cases.rs

As per coding guidelines: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/poa_cases.rs` around lines 19 - 20, The
async test function multi_slot_poa_test is using #[tokio::test] but needs the
tracing-aware wrapper; replace the attribute on the multi_slot_poa_test function
with #[test_log::test(tokio::test)] so tracing is initialized and test logs are
captured (no other code changes required).

crates/chain-tests/src/validation/blobs_rejected.rs (1)

239-239: ⚠️ Potential issue | 🟡 Minor

Complete the prefix removal on the last blob-rejection test.

Line 239 still leaves a heavy_ prefix while the three sibling blob-rejection tests above were renamed to the unprefixed evm_payload_* form. That keeps this case in a different nextest bucket from the rest of the suite.

✏️ Proposed fix

-async fn heavy_evm_payload_with_versioned_hashes_is_rejected() -> eyre::Result<()> {
+async fn evm_payload_with_versioned_hashes_is_rejected() -> eyre::Result<()> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/blobs_rejected.rs` at line 239, The test
function name still has a heavy_ prefix
(heavy_evm_payload_with_versioned_hashes_is_rejected) while the sibling tests
were renamed to evm_payload_*; rename this function to
evm_payload_with_versioned_hashes_is_rejected to match the others and keep it in
the same nextest bucket, and update any references (calls, re-exports,
documentation comments or test name strings) that reference
heavy_evm_payload_with_versioned_hashes_is_rejected so they point to the new
evm_payload_with_versioned_hashes_is_rejected symbol.

crates/chain-tests/src/api/external_api.rs (1)

15-17: 🧹 Nitpick | 🔵 Trivial

Use test_log attribute instead of manual tracing init here.

This tracing-enabled async test should use #[test_log::test(tokio::test)] and drop explicit initialize_tracing().

♻️ Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn external_api() -> eyre::Result<()> {
-    initialize_tracing();

As per coding guidelines **/*.rs: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/external_api.rs` around lines 15 - 17, Replace the
manual tracing initialization in the async test `external_api` by using the
test_log attribute: change the attribute on the `external_api` function from
`#[tokio::test]` to `#[test_log::test(tokio::test)]` and remove the
`initialize_tracing()` call from the function body so tracing is provided by the
attribute instead.

crates/chain-tests/src/validation/data_tx_pricing.rs (1)

148-149: ⚠️ Potential issue | 🟠 Major

Still using actix_web::test in test_log on async tests.

Line 148 and Line 272 should use Tokio runtime in test_log.

As per coding guidelines **/*.rs: "Use #[tokio::test] for async tests" and "Use #[test_log::test(tokio::test)] for tests that require tracing output".

Also applies to: 272-273

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/data_tx_pricing.rs` around lines 148 - 149,
The test attribute uses actix_web::test but per guidelines async tests should
use Tokio; replace the #[test_log::test(actix_web::test)] attribute on the async
test function block_insufficient_term_fee_gets_rejected (and the similar test at
the other occurrence) with #[test_log::test(tokio::test)] (or #[tokio::test] if
tracing/log output is not needed) so the test runs under the Tokio runtime
instead of actix_web's test runtime.

crates/chain-tests/src/synchronization/mod.rs (1)

273-276: 🧹 Nitpick | 🔵 Trivial

Use max_seconds-derived peer wait attempts instead of literal 100.

Line [275] still hardcodes retry attempts; this was previously flagged and remains unresolved.

♻️ Suggested tweak

-    genesis_node
-        .wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(), 100)
-        .await?;
+    let peer_wait_attempts = (max_seconds * 10) as usize; // wait_until_sees_peer polls every 100ms
+    genesis_node
+        .wait_until_sees_peer(
+            &peer.node_ctx.config.node_config.peer_address(),
+            peer_wait_attempts,
+        )
+        .await?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/synchronization/mod.rs` around lines 273 - 276, The
call to genesis_node.wait_until_sees_peer(...) is still passing a hardcoded
retry count 100; replace that literal with the derived max_seconds (or the
variable used elsewhere for configured retry attempts) so the peer wait uses the
centralized timeout configuration. Locate the call to
genesis_node.wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(),
100) and change the second argument to the existing max_seconds variable (or the
computed attempts variable used in the surrounding synchronization logic) to
avoid hardcoding retries.

crates/chain-tests/src/api/hardfork_tests.rs (1)

328-328: ⚠️ Potential issue | 🟠 Major

Restore tier prefixes for these two renamed tests.

Line [328] and Line [630] now bypass prefix-based nextest overrides, changing timeout/thread behavior.

Suggested rename patch

-async fn test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
+async fn heavy_test_boundary_crossing_v1_behavior() -> eyre::Result<()> {

-async fn test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {
+async fn heavy_test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {

Also applies to: 630-630

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/hardfork_tests.rs` at line 328, The test names
lost their nextest tier prefixes when renamed; restore the original prefix-based
test names so nextest overrides (timeouts/threads) apply — specifically update
the renamed test function test_boundary_crossing_v1_behavior and the other
renamed test around the later occurrence to reinstate the original tier prefix
(the same string that was removed) in their test identifiers so nextest picks up
the tier overrides.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (2)

753-773: ⚠️ Potential issue | 🟠 Major

Mark verification-required downgrades as non-auto-applicable.

These branches explicitly say "verify contention sensitivity," but safe_to_apply stays true, so cmd_apply() will still rename them automatically. Line 753 and Line 765 need the same manual-review gate as the spike-justified branch above.

Proposed fix

                 } else if duration >= LONG_TEST_DURATION_MS {
+                    safe_to_apply = false;
                     // Long I/O test: biggest performance opportunity, but also
                     // most sensitive to contention
                     issues.push(format!(
@@
                 } else {
+                    safe_to_apply = false;
                     // Medium-duration I/O test
                     issues.push(format!(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 753 -
773, The branches that push messages for long-duration and medium-duration I/O
tests currently leave safe_to_apply true, so they get auto-applied; update the
branches that call issues.push(...) in the long I/O and medium I/O cases (the
blocks that format messages with "verify contention sensitivity") to set
safe_to_apply = false (same manual-review gate as the spike-justified branch) so
cmd_apply() won't auto-rename those cases; make sure to set safe_to_apply before
continuing so the decision logic honors the manual verification requirement.

---

2802-2829: ⚠️ Potential issue | 🟠 Major

Skip commented-out signatures when locating definitions.

A line like // pub async fn foo() still passes the current before_fn.ends_with("pub async ") guard. If that wins the score, apply rewrites the comment line and misses the real function.

Proposed fix

         for (line_idx, line) in content.lines().enumerate() {
             let trimmed = line.trim();
+            if trimmed.starts_with("//") {
+                continue;
+            }
             if trimmed.contains(&pattern) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 2802 -
2829, Skip lines that are commented out before treating them as function
definitions: inside the loop over content.lines() where you compute trimmed,
early-return (continue) if trimmed starts with comment markers (e.g.,
trimmed.starts_with("//") or trimmed.starts_with("/*") or
trimmed.starts_with("///") or trimmed.starts_with("//!") ) so the existing
guards around before_fn, pattern, and the candidate push (variables/methods:
content.lines(), trimmed, before_fn, pattern, candidates) never consider
commented-out signatures.

crates/chain-tests/src/multi_node/validation.rs (1)

320-322: ⚠️ Potential issue | 🟡 Minor

Remove or update the stale heavy3_ scheduler note.

The function now uses the heavy_ prefix, so this comment still advertising the old 3-thread class is misleading for anyone checking CI allocation behavior.

Proposed fix

-// "heavy3_" prefix: requires 3 CI threads (see .config/nextest.toml)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/multi_node/validation.rs` around lines 320 - 322,
Update the stale scheduler note above the test
heavy_block_shadow_txs_different_order_of_txs: remove or change the "heavy3_"
prefix comment to reflect the current "heavy_" prefix (or remove the line
entirely) so the CI thread allocation guidance matches the test name; edit the
comment immediately above the #[test_log::test(tokio::test)] annotation for that
function to avoid misleading references to the old 3-thread class.

design/docs/spike-aware-test-group-scheduling.md (1)

3-4: ⚠️ Potential issue | 🟡 Minor

Add blank lines after these headings.

markdownlint will keep flagging MD022 until the heading at Line 3 and the heading at Line 88 are each followed by a blank line.

Proposed fix

 ## Status
+
 Accepted
@@
 ## Source
+
 Plan: `docs/superpowers/plans/2026-03-24-spike-aware-test-groups.md` — Spike-Aware Test Group Scheduling

Also applies to: 88-89

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@design/docs/spike-aware-test-group-scheduling.md` around lines 3 - 4, Add a
single blank line immediately after each top-level heading to satisfy
markdownlint MD022; specifically insert one blank line after the "Status"
heading and after the later top-level heading near the end of the document so
each heading is followed by an empty line before the next paragraph or content.

crates/p2p/src/tests/util.rs (1)

1147-1152: ⚠️ Potential issue | 🟡 Minor

Enforce deadline before evaluating check() in poll_until.

Current ordering can return Ok(()) slightly past timeout, which weakens the helper’s contract.

Suggested fix

 pub(crate) async fn poll_until(
     timeout: Duration,
     msg: &str,
     check: impl Fn() -> bool,
 ) -> eyre::Result<()> {
     let deadline = tokio::time::Instant::now() + timeout;
     loop {
+        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         if check() {
             return Ok(());
         }
-        eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}");
         tokio::time::sleep(Duration::from_millis(100)).await;
     }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/p2p/src/tests/util.rs` around lines 1147 - 1152, The loop in
poll_until evaluates check() before verifying the deadline, allowing a success
to be returned after timeout; modify the loop in poll_until so the
eyre::ensure!(tokio::time::Instant::now() < deadline, "{msg}") is executed
before calling check(), ensuring the deadline is enforced prior to returning
Ok(()). Keep the existing sleep(Duration::from_millis(100)).await between
iterations and retain the same error message semantics.

.config/nextest.toml (1)

32-44: 🧹 Nitpick | 🔵 Trivial

Remove commented priority entries to keep scheduling rules unambiguous.

These leftover commented values make it harder to read the active policy and were previously flagged.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.config/nextest.toml around lines 32 - 44, Remove the leftover commented
"priority" entries from the nextest profile overrides so scheduling rules are
unambiguous: edit the blocks that define [[profile.default.overrides]] (the
entries containing filter = 'test(/.*heavy3_.*/)...' and filter =
'test(/.*heavy4_.*/)...') and delete the commented lines like "# priority = 90",
"# priority = 80", "# priority = 70" so only the active keys (filter,
threads-required) remain.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (2)

2802-2832: 🧹 Nitpick | 🔵 Trivial

Function definition search may match false positives in edge cases.

A line containing a valid function definition followed by a comment with another fn could match incorrectly. For example:

pub fn bar() { } // fn foo()

When searching for foo, the validation would accept this because "pub " is a valid prefix before the first fn.

While rare in practice, adding a simple comment-line skip could prevent this:

 for (line_idx, line) in content.lines().enumerate() {
     let trimmed = line.trim();
+    // Skip pure comment lines
+    if trimmed.starts_with("//") {
+        continue;
+    }
     if trimmed.contains(&pattern) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 2802 -
2832, The current function-search loop can match a name that only appears inside
an end-of-line comment (e.g., `pub fn bar() { } // fn foo()`); to fix, strip or
ignore trailing line comments before running the existing validation: compute a
code-only portion (e.g., take the substring before "//" and optionally handle
"/* ... */" or other comment forms) and use that code_part in place of trimmed
for contains/find/before_fn/after_name_start checks (references:
variables/values `content.lines()`, `trimmed`, `pattern`, `before_fn`,
`after_name_start`, and `candidates.push`).

---

3080-3086: 🧹 Nitpick | 🔵 Trivial

Add cargo clippy to the post-apply checklist.

The post-apply instructions omit the repository's required lint step. As per coding guidelines, cargo clippy --workspace --tests --all-targets should be run before pushing.

Suggested fix

 println!("Next steps:");
 println!("  1. Run `cargo fmt --all` to format changed files");
-println!("  2. Run `cargo xtask check` to verify compilation");
-println!("  3. Run `cargo xtask test --monitor` to verify with updated classifications");
+println!("  2. Run `cargo clippy --workspace --tests --all-targets` to check for lint issues");
+println!("  3. Run `cargo xtask check` to verify compilation");
+println!("  4. Run `cargo xtask test --monitor` to verify with updated classifications");
 if clamped_count > 0 {
-    println!("  4. Run `apply` again to continue stepping down clamped tests");
+    println!("  5. Run `apply` again to continue stepping down clamped tests");
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 3080 -
3086, The post-apply checklist printed by the function that writes the "Next
steps" (the println block with "Run `cargo fmt --all`...", "Run `cargo xtask
check`...", etc. and the clamped_count conditional) is missing the required lint
step; update that println sequence to include a line printing the command "Run
`cargo clippy --workspace --tests --all-targets` to run the repository linter"
(insert it as its own numbered step in the list, adjusting numbers if desired)
so the output includes the clippy requirement alongside the existing
fmt/check/test instructions.

Fix all unresolved CodeRabbit comments on this PR:

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

crates/chain-tests/src/validation/blobs_rejected.rs (1)

239-239: ⚠️ Potential issue | 🟡 Minor

Complete the rename here as well.

Line 239 still keeps heavy_, unlike the other renamed tests in this file.

Proposed fix

-async fn heavy_evm_payload_with_versioned_hashes_is_rejected() -> eyre::Result<()> {
+async fn evm_payload_with_versioned_hashes_is_rejected() -> eyre::Result<()> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/blobs_rejected.rs` at line 239, Rename the
test function heavy_evm_payload_with_versioned_hashes_is_rejected to match the
other renamed tests by removing the "heavy_" prefix: update the async fn
declaration heavy_evm_payload_with_versioned_hashes_is_rejected() ->
eyre::Result<()> to evm_payload_with_versioned_hashes_is_rejected() ->
eyre::Result<()> and update any references or attributes that call or reference
heavy_evm_payload_with_versioned_hashes_is_rejected (e.g., #[tokio::test] or
mod-level invocations) to use the new
evm_payload_with_versioned_hashes_is_rejected symbol so names remain consistent.

crates/chain-tests/src/api/tx_commitments.rs (1)

342-343: ⚠️ Potential issue | 🟡 Minor

Use test-log wrapper for this tracing-heavy async test.

This test emits tracing output but is still using #[tokio::test]; use the test_log wrapper instead.

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn heavy_no_commitments_basic_test() -> eyre::Result<()> {

As per coding guidelines: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/tx_commitments.rs` around lines 342 - 343, Replace
the test attribute on the async test function heavy_no_commitments_basic_test
from #[tokio::test] to the tracing-enabled wrapper
#[test_log::test(tokio::test)] so tracing output is captured; update the
attribute above the heavy_no_commitments_basic_test function accordingly (no
other code changes required).

crates/chain-tests/src/validation/poa_cases.rs (1)

19-23: ⚠️ Potential issue | 🟡 Minor

Use tracing-aware test attribute for this async test.

Line 19 uses #[tokio::test], but this test initializes tracing and emits info! logs. Please use #[test_log::test(tokio::test)] here.

Suggested patch

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn multi_slot_poa_test() -> eyre::Result<()> {

As per coding guidelines: "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/validation/poa_cases.rs` around lines 19 - 23, Replace
the #[tokio::test] attribute on the async test function multi_slot_poa_test with
the tracing-aware attribute #[test_log::test(tokio::test)] so the tracing
initialization and emitted info! logs (from initialize_tracing and the test
body) are captured during test runs; update the attribute above the
multi_slot_poa_test fn accordingly.

crates/chain-tests/src/api/hardfork_tests.rs (1)

328-328: ⚠️ Potential issue | 🟠 Major

Restore tier-prefixed names for these two heavy-path tests.

Line 328 and Line 630 were renamed to test_*, which can drop them out of regex-based nextest tier overrides (timeouts/resources), increasing CI flake risk.

Suggested patch

-    async fn test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
+    async fn heavy_test_boundary_crossing_v1_behavior() -> eyre::Result<()> {
...
-    async fn test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {
+    async fn heavy_test_epoch_at_hardfork_boundary_doesnt_filter_v1() -> eyre::Result<()> {

Also applies to: 630-630

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/api/hardfork_tests.rs` at line 328, The test function
currently named test_boundary_crossing_v1_behavior was renamed from a
tier-prefixed heavy-test name and should be restored to its original
tier-prefixed form so nextest regex-based overrides still match; locate the
function named test_boundary_crossing_v1_behavior in this file and rename it
back to the CI tier prefix convention (for example
tier_heavy_boundary_crossing_v1_behavior or whatever the repo's tier prefix is),
and do the same for the other heavy-path test in this file that was also renamed
to a plain test_* name (restore its original tier-prefixed identifier) so both
heavy tests match the nextest tier overrides.

crates/chain-tests/src/synchronization/mod.rs (1)

273-276: 🧹 Nitpick | 🔵 Trivial

Derive peer-wait attempts from max_seconds instead of hardcoding 100.

Line 275 hardcodes retry attempts despite having max_seconds in scope; deriving attempts keeps timing intent explicit and easier to maintain.

♻️ Proposed refactor

-    // Wait for peer to connect
+    // Wait for peer to connect (wait_until_sees_peer polls every 100ms)
+    let peer_wait_attempts = (max_seconds * 10) as usize;
     genesis_node
-        .wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(), 100)
+        .wait_until_sees_peer(
+            &peer.node_ctx.config.node_config.peer_address(),
+            peer_wait_attempts,
+        )
         .await?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/synchronization/mod.rs` around lines 273 - 276,
Replace the hardcoded retry count 100 in the call to
genesis_node.wait_until_sees_peer(...) with a value derived from the existing
max_seconds variable: use max_seconds (or compute attempts from max_seconds if
wait_until_sees_peer expects attempts per second) so the call becomes
genesis_node.wait_until_sees_peer(&peer.node_ctx.config.node_config.peer_address(),
max_seconds). This keeps the retry semantics tied to the max_seconds
configuration and removes the magic number.

crates/chain-tests/src/data_sync/sync_partition_data_tests.rs (1)

24-25: ⚠️ Potential issue | 🟠 Major

Switch this tracing-heavy async test to #[test_log::test(tokio::test)].

Given explicit tracing initialization and frequent log emission, plain #[tokio::test] is not guideline-compliant here.

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn spiky_slow_heavy4_sync_partition_data_between_peers_test() -> eyre::Result<()> {

As per coding guidelines "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/data_sync/sync_partition_data_tests.rs` around lines
24 - 25, Replace the test attribute on the async test function
spiky_slow_heavy4_sync_partition_data_between_peers_test: change #[tokio::test]
to #[test_log::test(tokio::test)] so tracing/logging is properly initialized for
this tracing-heavy test; if test_log is not already available, add the test_log
dependency and appropriate use so the attribute macro resolves.

crates/chain-tests/src/promotion/promotion_with_multiple_proofs.rs (1)

7-8: ⚠️ Potential issue | 🟠 Major

Use test_log wrapper for this tracing-enabled async test.

This test initializes tracing and emits logs, so it should use the logging-aware wrapper instead of plain #[tokio::test].

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn spiky_heavy4_promotion_with_multiple_proofs_test() -> eyre::Result<()> {

As per coding guidelines "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/promotion/promotion_with_multiple_proofs.rs` around
lines 7 - 8, The test attribute on
spiky_heavy4_promotion_with_multiple_proofs_test should be changed to the
tracing-aware wrapper: replace #[tokio::test] with
#[test_log::test(tokio::test)] so the async test uses the test_log harness and
emits tracing output correctly; update the attribute above the async fn
spiky_heavy4_promotion_with_multiple_proofs_test() accordingly.

crates/chain-tests/src/startup/genesis.rs (1)

12-14: ⚠️ Potential issue | 🟠 Major

Use #[test_log::test(tokio::test)] for this tracing-enabled async test.

The test initializes tracing explicitly, so it should use the repository’s tracing-aware test attribute wrapper.

Suggested fix

-#[tokio::test]
+#[test_log::test(tokio::test)]
 async fn test_genesis_state_dump_and_restore() -> eyre::Result<()> {

As per coding guidelines "Use #[test_log::test(tokio::test)] for tests that require tracing output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/startup/genesis.rs` around lines 12 - 14, Replace the
plain #[tokio::test] attribute on the async test function
test_genesis_state_dump_and_restore with the tracing-aware wrapper
#[test_log::test(tokio::test)] and remove the manual initialize_tracing() call
at the start of that test so tracing is handled by the test attribute; keep the
function signature and return type unchanged.

crates/chain-tests/src/multi_node/validation.rs (1)

317-322: 🧹 Nitpick | 🔵 Trivial

Remove the stale heavy3_ scheduler note.

Line 320 still documents a heavy3_ tier, but the test is now named heavy_block_shadow_txs_different_order_of_txs. Leaving the old prefix here will mislead future classification changes.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/multi_node/validation.rs` around lines 317 - 322, The
comment above the test references a stale "heavy3_" scheduler tier; update the
header to remove or correct that prefix so it matches the test name
heavy_block_shadow_txs_different_order_of_txs and current CI classification—edit
the block comment immediately preceding the #[test_log::test] and fn
heavy_block_shadow_txs_different_order_of_txs() to drop the "heavy3_" note or
replace it with the appropriate, current scheduler annotation.

crates/chain-tests/src/promotion/data_promotion_basic.rs (1)

289-290: ⚠️ Potential issue | 🟠 Major

Switch these renamed async tests off #[actix_web::test].

Line 289 and Line 408 still use Actix's test runtime even though these tests explicitly configure tracing and this suite standardizes on Tokio. Please move both to #[test_log::test(tokio::test)].

♻️ Suggested fix

-#[actix_web::test]
+#[test_log::test(tokio::test)]
 async fn promotion_validates_submit_inclusion_test() -> eyre::Result<()> {

-#[actix_web::test]
+#[test_log::test(tokio::test)]
 async fn promotion_validates_ingress_proof_anchor() -> eyre::Result<()> {

Run this to confirm the two renamed tests still use the Actix macro while setting up tracing:

#!/bin/bash
rg -n -C1 '#\[actix_web::test\]|initialize_tracing\(\)|set_var\(\s*"RUST_LOG"' crates/chain-tests/src/promotion/data_promotion_basic.rs

As per coding guidelines, Use #[tokio::test] for async tests and Use #[test_log::test(tokio::test)] for tests that require tracing output.

Also applies to: 408-409

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/promotion/data_promotion_basic.rs` around lines 289 -
290, The test function promotion_validates_submit_inclusion_test (and the other
renamed async test in the same file) are still annotated with Actix's
#[actix_web::test] but the suite standardizes on Tokio and uses tracing; replace
the actix attribute with the tracing-enabled Tokio macro by changing
#[actix_web::test] to #[test_log::test(tokio::test)] on
promotion_validates_submit_inclusion_test and the other async test so they run
on the Tokio runtime and emit tracing output; search for the functions by name
to locate and update their attributes (look for
promotion_validates_submit_inclusion_test and the second test in
data_promotion_basic.rs).

crates/chain-tests/src/utils.rs (1)

2865-2886: 🧹 Nitpick | 🔵 Trivial

Add wait-state diagnostics to the new chunk waiter.

This is now the main sync point for async chunk migration, but its timeout still omits the node/index state that the neighboring waiters emit. When this stalls, the failure is much harder to root-cause.

♻️ Suggested instrumentation

+    #[diag_slow(state = format!(
+        "ledger={:?} chunk_offset={} {}",
+        ledger,
+        u64::from(chunk_offset),
+        self.diag_wait_state().await
+    ))]
     pub async fn wait_for_chunk_in_storage(
         &self,
         ledger: DataLedger,
         chunk_offset: LedgerChunkOffset,
         max_seconds: usize,
     ) -> eyre::Result<PackedChunk> {
         for _attempt in 1..=max_seconds {
             if let Some(chunk) = self.get_chunk(ledger, chunk_offset).await {
                 return Ok(chunk);
             }
             tokio::time::sleep(Duration::from_secs(1)).await;
         }
+        let state = self.diag_wait_state().await;
         Err(eyre::eyre!(
-            "Chunk not found in storage after {}s: {} ledger chunk_offset: {}",
+            "Chunk not found in storage after {}s: {} ledger chunk_offset: {}; state: {}",
             max_seconds,
             ledger,
             chunk_offset,
+            state,
         ))
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/chain-tests/src/utils.rs` around lines 2865 - 2886, The
wait_for_chunk_in_storage function lacks diagnostics when it times out; update
it to emit periodic state diagnostics during the retry loop and to include
node/index state in the final error message: on each failed attempt log a brief
diagnostic (attempt number and any available index/storage status) and, before
returning the eyre::eyre! error, collect the same node/index diagnostic values
used by the neighboring waiter helpers (copy the calls they use) and append them
to the error string so the final message includes ledger, chunk_offset plus
current node/index/storage state; reference wait_for_chunk_in_storage and
get_chunk to locate where to add the logging/diagnostic collection and reuse the
existing neighbor-waiter diagnostic helpers.

crates/utils/nextest-monitor/src/bin/nextest-report.rs (3)

753-773: ⚠️ Potential issue | 🟠 Major

Mark the verification-only I/O downgrades as non-auto-applicable.

These branches still leave safe_to_apply as true, so cmd_apply() will rename tests that analyze explicitly says to “verify contention sensitivity” first.

Suggested fix

                 } else if duration >= LONG_TEST_DURATION_MS {
+                    safe_to_apply = false;
                     // Long I/O test: biggest performance opportunity, but also
                     // most sensitive to contention
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — long-running I/O test, wastes {:.0}s thread-time. High perf impact, but verify contention sensitivity",
                         test.avg_avg_cpu.unwrap_or(0.0),
@@
                 } else {
+                    safe_to_apply = false;
                     // Medium-duration I/O test
                     issues.push(format!(
                         "CPU over-allocated: avg={:.2}x, peak={:.2}x (below {}T), {} duration — I/O-bound, {:.0}s thread-time wasted. Verify contention sensitivity before downgrading",
                         test.avg_avg_cpu.unwrap_or(0.0),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 753 -
773, In the two branches that push "I/O-bound" / "long-running I/O test" issues
(the blocks that call issues.push(...) for duration >= LONG_TEST_DURATION_MS and
the else medium-duration branch), mark these findings as verification-only by
setting safe_to_apply = false immediately when you push the issue; this ensures
cmd_apply() won't auto-rename tests that the analyzer warns should "verify
contention sensitivity" first. Reference the local variable safe_to_apply and
the issues.push(...) sites (the long I/O and medium I/O branches) and update
them to flip safe_to_apply to false.

---

3080-3085: ⚠️ Potential issue | 🟡 Minor

Include clippy in the post-apply checklist.

apply rewrites Rust sources, but the printed next steps omit the repo’s required lint pass.

Suggested fix

     println!("Next steps:");
     println!("  1. Run `cargo fmt --all` to format changed files");
-    println!("  2. Run `cargo xtask check` to verify compilation");
-    println!("  3. Run `cargo xtask test --monitor` to verify with updated classifications");
+    println!("  2. Run `cargo clippy --workspace --tests --all-targets` to catch lint failures");
+    println!("  3. Run `cargo xtask check` to verify compilation");
+    println!("  4. Run `cargo xtask test --monitor` to verify with updated classifications");
     if clamped_count > 0 {
-        println!("  4. Run `apply` again to continue stepping down clamped tests");
+        println!("  5. Run `apply` again to continue stepping down clamped tests");
     }

As per coding guidelines, "Run cargo clippy --workspace --tests --all-targets before pushing or creating PRs".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 3080 -
3085, The post-apply checklist printed in the block that starts with
println!("Next steps:") and uses clamped_count to conditionally add step 4 is
missing the required clippy lint step; update that printing block (the same
place that prints the fmt, xtask check, and xtask test lines) to include a line
instructing the user to run `cargo clippy --workspace --tests --all-targets`
(e.g., as an additional numbered step before pushing/creating PRs), ensuring the
new println is included alongside the existing printlns that reference
clamped_count.

---

396-419: ⚠️ Potential issue | 🟡 Minor

Don’t stop test(/.../) parsing at the first ) inside the regex.

after_test.find(')') truncates valid filters like test(/foo(bar|baz)/), so the loader silently builds the wrong include/exclude regex. Scan for the closing /) pair instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/utils/nextest-monitor/src/bin/nextest-report.rs` around lines 396 -
419, The code stops parsing a test(/.../) filter at the first ')' by using
after_test.find(')'), which breaks when the regex contains parentheses; change
the logic in the loop that computes close/inner (around remaining, after_test,
inner, pattern, is_exclude) to locate the closing "/)" sequence instead of a
lone ')'. Concretely, scan after_test for the substring "/)" (or find a '/' that
is immediately followed by ')'), compute the close index as the position of that
')' and set inner to the characters inside the slashes (so inner excludes the
closing '/'), then keep the existing strip_prefix/format and push to
includes/excludes and advance remaining past the "/)".

Fix all unresolved CodeRabbit comments on this PR:

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