PR #6418 hit a libp2p-kad CI failure in an unrelated change set. The failure looks like a flaky real-time bound in a Kad bootstrap test, and it can block PRs that do not touch Kad.
Failed CI:
The failing test was:
bootstrap::tests::given_periodic_bootstrap_when_routing_table_updated_then_wont_bootstrap_until_next_interval
The job log shows:
thread 'bootstrap::tests::given_periodic_bootstrap_when_routing_table_updated_then_wont_bootstrap_until_next_interval' panicked at protocols/kad/src/bootstrap.rs:275:9:
assertion failed: elapsed < MS_5 * 2
test result: FAILED. 72 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 75.93s
The assertion is checking that a bootstrap scheduled with MS_5 completes in less than MS_5 * 2, so the test depends on a 10 ms wall-clock bound:
const MS_5: Duration = Duration::from_millis(5);
let start = Instant::now();
await_and_do_bootstrap(&mut status).await;
let elapsed = Instant::now().duration_since(start);
assert!(elapsed < MS_5 * 2);
Why this looks unrelated to PR #6418:
- The PR branch did not change
protocols/kad.
- The changed files were limited to dependency metadata,
libp2p-dns, libp2p-mdns, libp2p-tls, the top-level builder DNS wiring, and changelogs.
- The
libp2p-kad dependency tree for normal/dev edges does not go through Hickory, DNS, or mDNS.
- The exact failing test passed locally once while investigating, and then passed five more times in a loop.
Suggested fix:
Make the test deterministic instead of asserting that a 5 ms timer completes within a 10 ms real-time budget on a shared CI runner. For example, use Tokio's paused time support if it fits this module, or relax/restructure the assertion so scheduler delay does not fail the test when the behavior is otherwise correct.
PR #6418 hit a
libp2p-kadCI failure in an unrelated change set. The failure looks like a flaky real-time bound in a Kad bootstrap test, and it can block PRs that do not touch Kad.Failed CI:
6d76360af4c7d9978aa11fa954d264b57a7d8ae7Test libp2p-kadThe failing test was:
The job log shows:
The assertion is checking that a bootstrap scheduled with
MS_5completes in less thanMS_5 * 2, so the test depends on a 10 ms wall-clock bound:Why this looks unrelated to PR #6418:
protocols/kad.libp2p-dns,libp2p-mdns,libp2p-tls, the top-level builder DNS wiring, and changelogs.libp2p-kaddependency tree for normal/dev edges does not go through Hickory, DNS, or mDNS.Suggested fix:
Make the test deterministic instead of asserting that a 5 ms timer completes within a 10 ms real-time budget on a shared CI runner. For example, use Tokio's paused time support if it fits this module, or relax/restructure the assertion so scheduler delay does not fail the test when the behavior is otherwise correct.