test: verify sanitizer build configuration - #1716

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thank you for this contribution, and sorry that it has had only the automated acknowledgement since August 18.

A sanitizer-configuration assertion changes the confidence we place in several test venues, so it needs a deliberate maintainer review even though the diff is test-only. I have now routed it in the maintainer test queue with normal priority.

The queue is quite full and review may still take some time, but the PR is no longer unclassified. No changes are requested from you at this triage stage.

Here is the deliberate review this was promised on 2026-09-03, and I am sorry it took another seventeen days on top of the wait you had already had. You were told it needed careful attention and then heard nothing, which is the worst combination.

The review verdict: this is a good change and it closes a real class of false green.

A sanitizer lane that runs a runner built without the sanitizer asserts coverage it does not have, and nothing in the output says so — the suite passes, the badge is green, and the protection was never there. That failure mode is not hypothetical here. In the last week alone this repository produced a green suite from a stale object file that did not contain the fix under test, and a green lane running a binary whose build flags nobody checked. Refusing to run suites when the runner disagrees with the lane that produced it is the right shape of fix: it fails closed, before any suite can report a misleading pass.

Details I want to credit specifically, because they are the parts that make it hold up:

Exact-match comparison. [ "$actual" != "$expected"$'\n' ] rather than a substring or a grep means a missing field, a duplicated field, or a future field nobody handled yet all fail closed. A looser check would have silently weakened the gate the first time someone added a third flag.

The marker trick. captured="$("$runner" --build-config && printf '%s' "$marker")" distinguishes "the probe failed" from "the probe printed nothing", which a bare $(...) cannot. That is the difference between a gate and a gate-shaped thing.

Windows binary mode. Setting _setmode(..., _O_BINARY) before printing means the runner's \n does not become \r\n and silently fail an exact comparison on one platform only. That is precisely the kind of cross-platform detail that otherwise surfaces months later as an unexplainable Windows-only red.

I checked one thing before raising it, and it was my misreading, not your scope creep. The diff moves the CBM_TEST_BUILD_FINGERPRINT block, and at first glance it looked like an unadvertised behaviour change riding along. It is a relocation — the block exists on main today at tests/test_main.c:928, and it has to move below the --build-config early exit or the flag would do environment setup before printing. No behaviour change, and your description was accurate.

Both red checks are ours, not yours:

• === VENDORED INTEGRITY CHECK FAILED === — your diff touches no vendored file. I ran the check against current main just now and it passes cleanly, so whatever that was, it is already resolved upstream of you.
• MSan daemon_bootstrap_fails_fast_when_daemon_dies_at_publication (test_daemon_bootstrap.c:1116) — the daemon family has a documented readiness-flake history on constrained runners, and this is that neighbourhood rather than anything your change reaches.

What I need from you is a rebase, and nothing else. The CI on this PR is from 2026-09-13 and main has moved a long way since — including #2196 and #2197 today, which also land on scripts/test.sh. A rebase gives us a current verdict on a tree where those two reds should not recur, and then I will merge it.

Thank you for your patience, and for writing the gate to fail closed rather than to be convenient.