codex-core full suite fails tracing event_enabled test that passes in isolation

Open 💬 0 comments Opened Jul 29, 2026 by sangoi-exe

What issue are you seeing?

The complete codex-core test suite fails
session::turn::tests::post_sampling_token_estimate_is_disabled_by_always_on_sinks,
while the exact same test passes when run alone.

The failing assertion is:

assertion failed: !tracing::event_enabled!(
    target: POST_SAMPLING_TOKEN_ESTIMATE_TARGET,
    tracing::Level::TRACE,
    turn_id,
    estimated_token_count,
    message
)

On current main, the full suite finished with 2,105 passing tests and this
single failure. The isolated test passed.

What steps can reproduce the bug?

Tested on upstream commit:

28f3f1f9ef4e9578a5f023f6b6eba018914a5342

Environment:

Ubuntu 24.04.2 LTS under WSL2
rustc 1.95.0 (59807616e 2026-04-14)

Run the complete crate suite with one test thread:

cd codex-rs
cargo test -p codex-core -- --test-threads=1

The test fails even with --test-threads=1.

Then run only the failing test:

cd codex-rs
cargo test -p codex-core \
  session::turn::tests::post_sampling_token_estimate_is_disabled_by_always_on_sinks \
  -- --exact

The isolated test passes.

What is the expected behavior?

The test should produce the same result in the complete suite and in isolation.
The complete codex-core suite should not depend on global tracing callsite or
subscriber state left by other tests.

Additional information

This test was added after the performance issue reported in #29260. That issue
describes the runtime cost that the guard fixes; it does not report this test
isolation failure.

tracing::event_enabled! is documented as an approximate check and tracing
callsite interest is global across dispatchers. The full-suite-only failure is
therefore consistent with leaked or globally cached tracing interest, but this
report does not assume a specific fix.

View original on GitHub ↗