Fix T072: the completeness check a session never reached - #14
Merged
Conversation
`no_provider_at_all_reports_what_is_missing` asserted that a session with no provider anywhere reports an *incomplete configuration* naming `--provider`. It never got there. Enforcement is resolved before configuration completeness, so a build without `--features enforce` refused the unenforced session first, and a build with it reported the missing *policy* instead — the assertion could not hold on either. `--host` settles enforcement on both builds, which is what lets the completeness failure be about the provider. No `skip_on_enforcement_build` guard, for the same reason its neighbours have one: this case exits at configuration and never starts a session, so no kernel is involved. That exposed the second half. The child inherited the developer's own `~/.config/bee/config.toml`, where a provider silently completes the very session this test means to leave incomplete — and a policy there contradicts `--host` outright. `run_with_stdin` now runs the child in an empty directory with HOME and XDG_CONFIG_HOME pointed at it, so what the session resolves from flags is the whole subject, as the file claims. Verified failing-then-passing on both a default and an `enforce` build; on the latter it runs rather than skipping. Closes T072. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three tests toggle the process-global NO_COLOR — `viz::grid`, `tui::theme_bridge`, `tui::markdown`. Each already checks both colour states in a single body, and each carries a comment explaining that this is to avoid racing a parallel test. They race each other: same test binary, different modules, concurrent by default. One clearing the variable while another has it set is enough to fail an assertion, which is how `a_recognized_fence_is_highlighted_and_no_color_strips_it` failed one run and passed the next on identical code. A shared lock in `viz::palette` serialises the three. Poisoning is ignored deliberately: a panicking test has already reported its failure, and refusing the lock afterwards would turn one failure into every failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The last known failing test on
main, plus a flake it uncovered. Test-only — no production code changes.T072 —
no_provider_at_all_reports_what_is_missingThe test asserted that a session with no provider anywhere reports an incomplete configuration naming
--provider. It never got there: enforcement is resolved before configuration completeness, so a default build refused the unenforced session first, and anenforcebuild reported the missing policy instead. The assertion could not hold on either build.--hostsettles enforcement identically on both, which is what lets the completeness failure be about the provider. Noskip_on_enforcement_build()guard — for the same reason its neighbours have one: this case exits at configuration and never starts a session, so no kernel is involved. Verified failing-then-passing on a default build and anenforcebuild, where it now runs rather than skips.Fixing that exposed a second cause. The child inherited the developer's own
~/.config/bee/config.toml— a provider there silently completes the very session this test means to leave incomplete, and a policy there contradicts--hostoutright.run_with_stdinnow runs the child in an empty directory withHOMEandXDG_CONFIG_HOMEpointed at it, so what the session resolves from flags is the whole subject, as the file's own header claims.The flake underneath
Running the full suite afterwards failed a test that had nothing to do with any of this. Three tests toggle the process-global
NO_COLOR—viz::grid,tui::theme_bridge,tui::markdown— and each already checks both colour states in one body, with a comment explaining that this is to avoid racing a parallel test. They race each other: same binary, different modules, concurrent by default.a_recognized_fence_is_highlighted_and_no_color_strips_itfailed one run and passed the next on identical code.A shared lock in
viz::paletteserialises the three. Poisoning is ignored deliberately: a panicking test has already reported its failure, and refusing the lock afterwards would turn one failure into every failure. Eight consecutive lib runs green.Verification
cargo fmt --all -- --checkandcargo clippy --workspace --all-targets --features sec,astgrep-rust,astgrep-python -- -D warningsclean. Full suite green at--features sec,astgrep-rust,astgrep-pythonwith no failures — the first time that has been true on this repo since before 016.🤖 Generated with Claude Code