Repository navigation
fix: don't hand nextest a phantom-only filterset in run - #81
Merged
Merged
Conversation
Deleting a test produces a hunk over exactly its own stored range, so it lands in `affected` — and when nothing else changed, it is the whole selection. It is also gone from `nextest list`, so the generated default-filter matches nothing and nextest's exit 4 propagates: a stale cache row reported as a test failure. `run` now hands nextest `Selection::live_selected()` and short-circuits with exit 0 when that is empty, noting the count either way. `status` renders the same note in the conditional tense so its prediction still matches what `run` does. `collect --diff` is untouched: it keeps phantoms deliberately and prunes their rows afterwards.
This was referenced Aug 26, 2026
This was referenced Sep 5, 2026
Merged
max-sixty
added a commit
that referenced
this pull request
Sep 18, 2026
Three fixes to `run` and to the output, with no new CLI surface, no report-JSON schema change, and no change to the grep-able `cargo-affected:` summary line — so a patch. Deleting a test no longer makes `run` exit 4 (#81). The deletion's diff hunk covers exactly the lines of the deleted test's own stored coverage range, so the test selects itself, and nextest is then handed a filterset matching nothing. `run` now restricts the filterset to tests still in the listing and exits 0 with a note when that leaves nothing; `status` predicts the same. A change committed since the last collect that nothing covers now reports as uncovered (#92). The empty-selection message keyed off the working tree while selection diffs against each reachable `collect_sha`, so the change read as "no uncommitted changes ... nothing to run" directly under the "N commit(s) since collect" notice. Count nouns in `collect` and `run` output agree with their numbers (#82): "1 binary" rather than "1 binaryy", "1 test to run" rather than "1 tests to run". Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
max-sixty
pushed a commit
to max-sixty/worktrunk
that referenced
this pull request
Sep 20, 2026
Weekly CI pin bump for the two third-party tool pins that drifted this week. - **cargo-affected** `=0.4.0` → `=0.4.1` — `affected.yaml`, both call sites - **cargo-nextest** `=0.9.144` → `=0.9.145` — `coverage.yaml`, `.github/actions/test-setup/action.yaml`, `.github/actions/tend-setup/action.yaml`, and `.codex/cloud.sh`, which the weekly checklist keeps level with `test-setup` Toolchain compatibility against the pinned `1.97.0`: `cargo-affected` 0.4.1 declares `rust-version = 1.94`, `cargo-nextest` 0.9.145 declares `1.91`. Both build under `baptiste0928/cargo-install`. The `.codex/cloud.sh` tarball URL resolves at the new version — `cargo-nextest-0.9.145-x86_64-unknown-linux-gnu.tar.gz` is published on the `cargo-nextest-0.9.145` tag. The `worktrunk` pin also drifted this week and is in its own PR — it is the `wt` that drives `wt hook pre-merge` on all three platforms, so a red matrix there shouldn't hold back these two. <details><summary>What the two releases change, against this repo's config</summary> **cargo-affected 0.4.1** carries two `run` fixes, both landing on the advisory `affected` legs: a committed uncovered change is now reported as uncovered rather than as "no changes" ([max-sixty/cargo-affected#92](max-sixty/cargo-affected#92)), and `run` no longer hands nextest a phantom-only filterset ([#81](max-sixty/cargo-affected#81)). **cargo-nextest 0.9.145**'s headline changes are profile-inheritance fixes — overrides defined in intermediate profiles are now applied, and a profile without `default-filter` inherits from its nearest ancestor rather than always from `profile.default`. Those are no-ops here: `.config/nextest.toml` defines only `profile.default` (plus its `junit` sub-table), sets no `default-filter`, and CI passes no `--tool-config-file`. The change that does reach this suite is [nextest-rs/nextest#3553](nextest-rs/nextest#3553): on Apple platforms, where the standard library can't create pipes with `FD_CLOEXEC` atomically, a concurrently-spawned test could inherit a sibling's capture pipe and the sibling was then reported as having leaked handles after exit. Nextest now creates capture pipes itself. That is a macOS-leg flake source removed, not a behavior change the suite has to absorb. </details> Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.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.
Deleting a test makes
cargo affected runexit 4 witherror: no tests to run.Deleting a test function produces a diff hunk over exactly the lines its own stored coverage range covers, so the deleted test is selected as
affected— and if the deletion is the only change, it is the whole selection. It is also gone from the currentnextest list, so the generateddefault-filtermatches nothing, and nextest's "no tests to run" exit propagates throughrun_tests. A stale cache row is reported to the caller as a test failure.collect --diffhas never had this problem: it passes--no-tests=warnand usesDiffPlan::live_selected_countafterwards to tell an all-phantom rerun from a runner-shim failure.runhad no equivalent.Repro
Against the two-module scratch project the functional suite uses, with the whole
test_multiplyblock deleted and nothing else changed:Exit code 4.
Change
Selection::live_selected()(new, inselection.rs) isselected()restricted to tests still in the listing.runhands nextest that subset instead of the full selection, and short-circuits with exit 0 when it is empty — there is no run to make, and asking nextest to run a phantom-only filterset can only produce the exit above. Both paths emit a note naming the count and pointing atcargo affected collectto drop the rows.statusgets the same note, in the conditional tense. Without it the dry run would predict a test thatrunnow visibly skips, which is the invariant #71 established.collect --diffis untouched — it keeps phantoms in its filterset deliberately, and prunes their rows afterwards.Tests
run_with_all_phantom_selection_exits_zero(functional) collects, deletestest_multiply, and asserts exit 0 plus the two new messages. Verified failing against pre-fixsrc/:run with an all-phantom selection must exit 0, got Some(4), witherror: no tests to runin the captured output.Two unit tests in
selection.rspinlive_selected()'s filtering and the notice's singular/plural agreement.cargo testis green (114 unit + 42 functional);cargo clippy --all-targetsis clean.Relationship to #39 / #41
Same exit-4 failure class, different trigger, disjoint fix. #41 keeps filter-mismatched tests (positional filters,
-E,#[ignore]) out of the selection by keying offfilter-match.status; its own comment notes that phantoms are deliberately not inlisting.excludedand stay inaffected. This handles that remaining source. The two should merge cleanly enough — #41 edits the top ofcomputeand the imports inrun.rs; this editsimpl Selectionand the tail ofrun().