cargo test fails in an interactive terminal: stats_requests_match_detail_so_spans_are_available_to_count asserts on ColorMode::Auto #166

Environment

• tgrep: v1.0.11 (the same code is still on main, search.rs:2404)
• OS: Arch Linux (CachyOS), Linux 7.2.8-1-cachyos x86_64
• rustc 1.98.1 (48a229cea 2026-09-01) / cargo 1.98.1 (797e8a9bc 2026-08-05)
• Affects both profiles: cargo test (debug) and cargo test --release

Steps to reproduce

git clone https://github.com/microsoft/tgrep.git
cd tgrep
cargo test --workspace

Run it from an interactive terminal. The same command with stdout on a pipe passes: cargo test --workspace | cat.

Single test:

cargo test -p tgrep-cli --bin tgrep -- search::tests::stats_requests_match_detail_so_spans_are_available_to_count

Expected vs actual

Expected: the suite passes.

Actual: tgrep-cli's unit tests report 286 passed; 1 failed, and cargo test exits non-zero.

Log output

test search::tests::stats_requests_match_detail_so_spans_are_available_to_count ... FAILED

failures:

---- search::tests::stats_requests_match_detail_so_spans_are_available_to_count stdout ----
thread 'search::tests::stats_requests_match_detail_so_spans_are_available_to_count' (315267) panicked at tgrep-cli/src/search.rs:2414:9:
assertion failed: !opts.wants_match_detail()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    search::tests::stats_requests_match_detail_so_spans_are_available_to_count

test result: FAILED. 286 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out; finished in 1.05s
error: test failed, to rerun pass `-p tgrep-cli --bin tgrep`

The rest of the workspace is green in both profiles (identical output except this test).

Cause

The test builds its options with ..Default::default():

let mut opts = SearchOptions {
    stats: true,
    ..Default::default()
};

Under cfg(test) the derived Default yields color: ColorMode::Auto, and wants_match_detail() (tgrep-cli/src/search.rs:271) begins with self.color.is_enabled(). ColorMode::Auto resolves through atty_check() → std::io::stdout().is_terminal() (tgrep-cli/src/output.rs:62 and :781). libtest captures output at the Rust level, not by replacing fd 1, so in an interactive terminal is_enabled() is true and wants_match_detail() stays true after opts.stats = false — which is what the second assertion rejects.

CI never hits it: on GitHub Actions stdout is a pipe, so is_terminal() is false.

Impact

Anyone running cargo test in a terminal sees a red suite. It also breaks downstream packagers that run the test suite from a terminal — it failed the Arch Linux AUR build of 1.0.11 (makepkg calls cargo test with a tty), which had to be worked around by piping the test output through cat.

Suggested fix

Pin the color mode in the test so it cannot read the ambient stdout:

let mut opts = SearchOptions {
    stats: true,
    color: ColorMode::Never,
    ..Default::default()
};

ColorMode is already imported in search.rs, so no new import is needed.

Optionally, resolve ColorMode::Auto to a concrete bool when the options are constructed instead of re-reading the process's stdout on every wants_match_detail() call; that would also keep server-side decisions from depending on the environment.