Created Cancelled
By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Let a failed control name the test that killed it A control is a no-op mutation, so it cannot legitimately be killed: a killed control means the suite is flaky or the harness is buggy, and it fails the run. But the report said only that one had failed, never which test killed it, and report.json carried nothing but a count. Survivors and timeouts each get their child's output; a failed control got none. The cause was one hardcoded Nothing. A child that exits non-zero is a kill and its output was discarded, which is right for the thousand-odd ordinary mutations of a healthy run, whose kill is expected and whose output says nothing. For a control the kill is the finding, so this dropped the evidence at exactly the moment it mattered. SuiteKilled now carries an optional log path, and the driver keeps the log only when the killed mutation is a control, under a control-failure- prefix. So the report gains one file per control failure rather than one per mutation, and the failed-control section points at it. Found while chasing a control that failed once in nix-ci, at a time-based wait computation, with no way to tell which test did it and no way to reproduce it outside a loaded mutation run.