Summary
Scheduled mutation-testing run 29103364052 (2026-07-10) failed after the mutant-generation stage with an AssertionError, not a sandbox or permission fault. Later scheduled runs (29155696532 07-11 through 29690446142 07-19) have all been green, but that is because none of them happened to change-detect a lone test-file edit within the 25-hour window — the underlying bug is still present.
Root cause
The Detect changed files step reported INPUT_FILES: hooks/test_post_turn_quality_stop_hook.py — the only file touched inside the 25-hour window was the test module itself, not post-turn-quality-stop-hook.py. The shared mutation-mutmut.yml caller mapped this changed path straight onto a mutmut module filter without stripping or excluding the test file:
mutmut run hooks.test_post_turn_quality_stop_hook.*
mutmut only generates mutants for source files, so the filter matches nothing, and collect_source_file_mutation_data raises:
AssertionError: Filtered for specific mutants, but nothing matches
Filter: ('hooks.test_post_turn_quality_stop_hook.*',)
The job then exits 1 (mutation_mutmut_exit_code=1).
Impact
Any scheduled run whose change-detection window contains only test-file edits (no source-file edits) will fail this way. It is a change-detection/filter defect in the shared caller, unrelated to actual mutant survival or code correctness, and is distinct from the known contract-test sandbox-restriction failure class.
Proposed next step
In the shared mutation-mutmut.yml workflow (or its change-detection step), exclude test-file paths from the derived mutmut module filter, or map a test-only change back to the source module(s) it exercises, before invoking mutmut run. Alternatively, skip the mutation step entirely (as already happens when has_changes=False) when the only changed paths are test files.
Reference
Summary
Scheduled mutation-testing run 29103364052 (2026-07-10) failed after the mutant-generation stage with an
AssertionError, not a sandbox or permission fault. Later scheduled runs (29155696532 07-11 through 29690446142 07-19) have all been green, but that is because none of them happened to change-detect a lone test-file edit within the 25-hour window — the underlying bug is still present.Root cause
The
Detect changed filesstep reportedINPUT_FILES: hooks/test_post_turn_quality_stop_hook.py— the only file touched inside the 25-hour window was the test module itself, notpost-turn-quality-stop-hook.py. The sharedmutation-mutmut.ymlcaller mapped this changed path straight onto a mutmut module filter without stripping or excluding the test file:mutmut only generates mutants for source files, so the filter matches nothing, and
collect_source_file_mutation_dataraises:The job then exits 1 (
mutation_mutmut_exit_code=1).Impact
Any scheduled run whose change-detection window contains only test-file edits (no source-file edits) will fail this way. It is a change-detection/filter defect in the shared caller, unrelated to actual mutant survival or code correctness, and is distinct from the known contract-test sandbox-restriction failure class.
Proposed next step
In the shared
mutation-mutmut.ymlworkflow (or its change-detection step), exclude test-file paths from the derived mutmut module filter, or map a test-only change back to the source module(s) it exercises, before invokingmutmut run. Alternatively, skip the mutation step entirely (as already happens whenhas_changes=False) when the only changed paths are test files.Reference