sempai mutation baseline: compile_yaml_emits_observable_compile_span fails under cargo-mutants (assert_event mismatch)

[leynos]

Context

Two scheduled mutation-testing runs failed quickly (baseline failure, not a real mutant run):

• run 29392119169 (2026-07-15, ~1.4 min)
• run 29675944487 (2026-07-19) — different cause, see below; not this issue

The 2026-07-15 run failed the unmutated baseline for the shard covering
crates/sempai-core/src/formula.rs, crates/sempai/src/engine.rs,
crates/sempai/src/normalize_constraints.rs, crates/sempai/src/semantic_check.rs
and the crates/sempai/src/tests/* files:

thread 'tests::tracing_tests::compile_yaml_emits_observable_compile_span' (5868) panicked at crates/sempai/src/tests/tracing_tests.rs:190:5:
   1: core::panicking::panic_fmt
   2: sempai::tests::tracing_tests::assert_event
   3: sempai::tests::tracing_tests::assert_compile_yaml_debug_events

failures:
    tests::tracing_tests::compile_yaml_emits_observable_compile_span

test result: FAILED. 82 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.08s
error: test failed, to rerun pass `-p sempai --lib`
mutation_cargo_exit_code=4
mutation_cargo_outcome=baseline tests failing

assert_event (line ~184–198) is the shared assertion helper used by
assert_compile_yaml_debug_events to check that a specific debug-level
tracing event (message + field matchers) is present in the events
captured during compile_yaml. One of the four expected events —
"yaml parsed successfully", "principal normalized",
"semantic validation passed", or "query plan created" — was not
found (or a field did not match) when the whole sempai test binary
ran under plain cargo test (the runner cargo-mutants uses for the
baseline), as opposed to cargo nextest run (one process per test),
which CI uses and which stays green.

Not the #183/#184 dispatcher-contention bug

This looked at first like another instance of #183 (weaverd baseline
failures from racing tracing::subscriber::set_global_default calls,
fixed by #184). It is not the same mechanism:
compile_yaml_emits_observable_compile_span already scopes its
subscriber correctly via tracing::subscriber::with_default(subscriber, || { ... })
(crates/sempai/src/tests/tracing_tests.rs:133), so there is no global
dispatcher race here. PR #184 only touched
crates/weaverd/src/dispatch/handler/tests_helpers.rs — it did not
touch sempai's tracing tests, so this failure was never in scope for
that fix.

The proximate cause is therefore an assert_event content/ordering
mismatch, not dispatcher contention. Plausible drivers to check:

• Whether Engine::compile_yaml's debug-event emission depends on
  something that differs between an isolated cargo nextest process
  and a shared cargo test binary process (e.g. a lazily-initialised
  static, a OnceLock/OnceCell shared across tests in the same
  binary, or ordering-dependent state left over from another test
  that ran first in the same process).
• Whether one of the four expected debug events is genuinely flaky
  (timing/ordering) rather than deterministic.

Ask

• Reproduce locally with cargo test -p sempai --lib tests::tracing_tests:: -- --test-threads=1 and with the default
  (parallel, shared-process) settings to see whether it is
  order/concurrency-dependent.
• If it is shared-state contamination from another test in the same
  binary, apply the same fix pattern as Scope the recording tracing subscriber to fix the mutation baseline #184: make any shared/global
  state used by compile_yaml's tracing instrumentation test-scoped,
  or isolate the debug-event capture the way
  tests_helpers::capture_events now does.
• If it is a genuine assertion/content regression (e.g. a field value
  or message text changed), fix the source or the assertion,
  whichever is correct.

References

• Run: https://github.com/leynos/weaver/actions/runs/29392119169/job/87277703434
• Related (different bug, already fixed): weaverd tests fail under plain cargo test, blocking the mutation-testing baseline #183, Scope the recording tracing subscriber to fix the mutation baseline #184
• Related (added the instrumentation under test): Add tracing spans and structured logging to the compile_yaml normalisation pipeline #115

[coderabbitai]

🔗 Related PRs

leynos/theoremc#38 - Add core+macros crates; implement theorem_file proc-macro (3.2.1) [closed]
#146 - Trace compile YAML pipeline (#115) [merged]
leynos/whitaker#235 - Implement rstest helper call-site collection (8.2.2) [open]
leynos/chutoro#143 - HNSW packed-index neighbour evaluation (2.3.1) [merged]
leynos/ortho-config#381 - Package-qualify mutation baseline features [merged]
leynos/wireframe#612 - Kill mutation-testing survivors and widen scaffolding excludes (#566, #567, #569, #570, #593, #595, #598) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!