fix(ci): allow concurrent wallet tests on CI#7229
Conversation
Walkthrough
ChangesNotEnoughFunds Error Enrichment
Calibnet Test Harness and CI Improvements
Sequence Diagram(s)sequenceDiagram
participant Runner as CalibnetMpoolTestCommand
participant Wrapper as mpool_replace_auto_unblocks_pending
participant BlockOn as block_on
participant RT as Tokio Runtime (new OS thread)
participant Async as mpool_replace_auto_unblocks_pending_async
Runner->>Wrapper: invoke (libtest-mimic, 8 threads)
loop retry 3 → 2 → 1
Wrapper->>BlockOn: catch_unwind(block_on(future))
BlockOn->>RT: spawn thread, build multi-thread runtime
RT->>Async: rt.block_on(future)
Async-->>RT: Result
RT-->>BlockOn: join thread result
BlockOn-->>Wrapper: Ok or Err
alt Ok
Wrapper-->>Runner: return Ok(())
else Err and retries remain
Wrapper->>Wrapper: sleep 5s, retry
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/dev/subcommands/tests_cmd/calibnet/helpers.rs (1)
388-400: 🩺 Stability & Availability | 🟡 MinorRemove unnecessary
Syncbounds; keep fresh runtime per call due to thread-spawned test execution.The test closures execute in threads spawned by
libtest_mimic's thread pool, not within the Tokio async context. Because there is no active runtime available viaHandle::current()in those threads, creating a fresh multi-thread runtime per call is architecturally necessary. However, theSyncbounds onFandF::Outputare overly restrictive—std::thread::spawnrequires onlySend, notSync.Suggested adjustment
pub fn block_on<F: Future + Send + 'static>(future: F) -> F::Output where - F::Output: Send + Sync + 'static, + F::Output: Send + 'static, { std::thread::spawn(|| { let rt = tokio::runtime::Builder::new_multi_thread() .enable_all() .build() .unwrap(); rt.block_on(future) }) .join() .unwrap() }🤖 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 `@src/dev/subcommands/tests_cmd/calibnet/helpers.rs` around lines 388 - 400, The generic bounds on the block_on function are overly restrictive. Remove the Sync trait bounds from both the F generic parameter and the F::Output associated type, keeping only the Send bounds since std::thread::spawn only requires Send. The function signature should be updated so that F and F::Output only require Send, not Sync, while preserving all other constraints and the implementation that spawns a fresh multi-thread Tokio runtime per call.Source: Learnings
🧹 Nitpick comments (1)
src/dev/subcommands/tests_cmd/calibnet/helpers.rs (1)
207-213: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winKeep
OnceCellinitialization failures contextual.Line 208 discards which backend failed, and Line 225 turns the whole init error into a bare panic. Since the initializer already returns
anyhow::Result, propagate the poll error with backend context and use a descriptiveexpectonly at the infallible API boundary.Proposed error-context cleanup
for backend in [Backend::Local, Backend::Remote] { - let funded = poll_until_funded(&addr, backend).await.unwrap(); + let funded = poll_until_funded(&addr, backend) + .await + .with_context(|| { + format!( + "delegated wallet {addr} was not funded via {}", + backend.label() + ) + })?; eprintln!( "delegated wallet {addr} funded balance: {funded} ({})", backend.label() ); } @@ }) .await - .unwrap() + .expect("failed to initialize funded delegated wallet") .as_str()If
anyhow::Contextis not already imported in this file, add it to the existinganyhowimports.As per coding guidelines, Rust operations should use
anyhow::Result<T>with.context()when errors occur and avoid bareunwrap()in production-style code.Also applies to: 225-226
🤖 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 `@src/dev/subcommands/tests_cmd/calibnet/helpers.rs` around lines 207 - 213, The poll_until_funded call on line 208 uses bare .unwrap() which discards context about which backend failed, making debugging difficult. Replace the .unwrap() with .context() to add backend context to the error, allowing the anyhow::Result to propagate meaningful error information instead of panicking silently. Include backend.label() or similar identifying information in the context message. Additionally, ensure anyhow::Context is imported in the file if not already present, and apply the same contextual error handling pattern to the similar issue on line 225 where init errors are turned into bare panics.Source: Coding guidelines
🤖 Prompt for all review comments with 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.
Outside diff comments:
In `@src/dev/subcommands/tests_cmd/calibnet/helpers.rs`:
- Around line 388-400: The generic bounds on the block_on function are overly
restrictive. Remove the Sync trait bounds from both the F generic parameter and
the F::Output associated type, keeping only the Send bounds since
std::thread::spawn only requires Send. The function signature should be updated
so that F and F::Output only require Send, not Sync, while preserving all other
constraints and the implementation that spawns a fresh multi-thread Tokio
runtime per call.
---
Nitpick comments:
In `@src/dev/subcommands/tests_cmd/calibnet/helpers.rs`:
- Around line 207-213: The poll_until_funded call on line 208 uses bare
.unwrap() which discards context about which backend failed, making debugging
difficult. Replace the .unwrap() with .context() to add backend context to the
error, allowing the anyhow::Result to propagate meaningful error information
instead of panicking silently. Include backend.label() or similar identifying
information in the context message. Additionally, ensure anyhow::Context is
imported in the file if not already present, and apply the same contextual error
handling pattern to the similar issue on line 225 where init errors are turned
into bare panics.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 3e820547-95e1-4544-998d-f81bc630518d
📒 Files selected for processing (1)
src/dev/subcommands/tests_cmd/calibnet/helpers.rs
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
filecoin-project/lotus(manual)
Summary of changes
Now it takes ~7min without blocking other PRs: https://github.com/ChainSafe/forest/actions/runs/28035122912/job/82987732860?pr=7229
Changes introduced in this pull request:
Reference issue to close (if applicable)
Closes
Other information and links
Change checklist
Outside contributions
Summary by CodeRabbit
Release Notes
Bug Fixes
Chores