Skip to content
Latchkey

Rust "cargo nextest" Failures - Leaked/Timed-Out Tests in CI

A cargo nextest run had at least one test that failed, leaked a child process, or exceeded its slow/leak timeout and was aborted. nextest runs each test in its own process, so its failure modes (LEAK, slow, timeout) differ from the built-in harness.

What this error means

nextest prints a summary with FAIL, LEAK, or TIMEOUT/ABORT lines and exits non-zero. A LEAK means the test passed but left a child process or open handle; a slow/timeout abort means it ran past the configured limit.

nextest output
        FAIL [   0.012s] app::math tests::divides
        LEAK [   5.030s] app::net tests::spawns_server
------------
     Summary [   5.1s] 24 tests run: 22 passed, 1 failed, 1 leaked
error: test run failed

Diagnose it: linker, target, or memory

Rust build failures in CI that are not compiler errors are usually a missing system linker or library, a target that is not installed, or the compiler being killed for memory.

Terminal
rustup target list --installed
cc --version || echo "no C toolchain: install build-essential"
free -h

# exit 137 during codegen is an out-of-memory kill, not a compile error
cargo build -j 2   # fewer parallel codegen units uses less memory

Common causes

A test assertion failed

Like the built-in harness, a FAIL line is a genuine failing test - an assertion didn’t hold or the test panicked. It reproduces on the same code.

A leaked process or a slow/timeout abort

nextest flags a LEAK when a test leaves a child process or handle open after returning, and aborts tests that exceed the slow-timeout/leak-timeout. A test spawning a server without cleaning it up is the classic leak.

How to fix it

Read the summary and reproduce the failure

  1. Identify each FAIL/LEAK/TIMEOUT line and the test it names.
  2. Re-run just that test with a filter expression, e.g. cargo nextest run -E "test(divides)".
  3. For a LEAK, ensure the test joins/kills any process or task it spawns before returning.

Tune timeouts deliberately, not to mask bugs

Raise the slow/leak timeout only for genuinely long tests; don’t use it to hide a hang or a leak.

.config/nextest.toml
# .config/nextest.toml
[profile.ci]
slow-timeout = { period = "60s", terminate-after = 2 }
leak-timeout = "1s"

How to prevent it

  • Clean up spawned processes/tasks in tests so they don’t leak.
  • Keep per-test timeouts tight enough to catch hangs but generous for real long tests.
  • Run cargo nextest run locally before pushing.

Frequently asked questions

What causes Rust "cargo nextest" failures?
There are 2 common causes: a test assertion failed and a leaked process or a slow/timeout abort. Like the built-in harness, a FAIL line is a genuine failing test - an assertion didn’t hold or the test panicked.
How do I fix Rust "cargo nextest" failures?
There are 2 fixes depending on which cause you have: read the summary and reproduce the failure and tune timeouts deliberately, not to mask bugs. Work through them in order, since the first is the most common.
What does Rust "cargo nextest" failures actually mean?
nextest prints a summary with FAIL, LEAK, or TIMEOUT/ABORT lines and exits non-zero.
How do I stop Rust "cargo nextest" failures happening again?
Clean up spawned processes/tasks in tests so they don’t leak. The prevention section lists 3 changes that keep it from recurring.

Related guides

References

Not every red build is your code. Latchkey repairs the ones that are not, on the runner. Start free → 30-day trial · No credit card