Мутационный гейт: Stryker считает выжившими мутантов, при прогоне которых не выполнилось ни одного теста

[tihonove]

В #272 мутационный гейт полдня держал PR красным на пустом месте: он объявлял выжившими мутантов, при прогоне которых не выполнялось ни одного теста.

Что происходит

В reports/mutation/mutation.json у таких мутантов testsCompleted: 0 при сотне покрывающих:

CallExpression  110:13   coveredBy: 99   testsCompleted: 0
LogicalOperator 122:17   coveredBy: 11   testsCompleted: 0

В trace-логе Stryker'а тот же прогон выглядит так:

Test Files  2 skipped (5)
     Tests  33 skipped (47)
   Duration  309ms ... tests 0ms

Ни одного упавшего теста нет — и Stryker пишет «мутант выжил».

Набор таких мутантов плавает от прогона к прогону. Один и тот же коммит на CI: 5 выживших → перезапуск той же джобы → 6 других. Локально по одному файлу два прогона подряд дали разных единственных выживших. При этом каждый из них при ручной подстановке в код валит от одного до четырёх тестов — то есть тесты их убивают, гейт просто их не запускает.

Что не помогает:

режим	результат
coverageAnalysis: perTest (как сейчас)	выжившие с testsCompleted: 0
coverageAnalysis: off	то же, другой набор
--maxTestRunnerReuse 1	хуже (5 вместо 2)
vitest.related: false	dry-run падает на постороннем тесте diffing fixtures difficult-move

Похоже на дефект связки @stryker-mutator/vitest-runner@10 ↔ vitest@4: в логе рядом висит DEPRECATED test.poolOptions was removed in Vitest 4 — раннер отдаёт vitest конфиг старого формата. Тем же классом хрупкости выглядит и RuntimeError: Test runner crashed. Tried twice to restart it, который иногда прилетает на отдельных мутантах (порог он не ломает — Stryker считает ошибки отдельной колонкой).

Что уже сделано

В #272 гейт (scripts/mutation-diff.mjs) научился различать «никто не заметил» и «ничего не запускали»: выживший с testsCompleted > 0 роняет прогон сразу, а нулевые перепроверяются вторым точечным прогоном по диапазону строк самого мутанта — там прогон надёжен. Перепроверенные помечаются в отчёте Killed с причиной; пустая перепроверка — падение, а не зелёный.

Это обходной путь, а не лечение.

Что стоит сделать дальше

1. Собрать минимальный воспроизводимый пример и завести issue в апстриме StrykerJS (или найти существующий — судя по симптомам, это должно всплывать у всех, кто на vitest 4).
2. Проверить, чинит ли проблему новая версия раннера, когда выйдет; после этого обходной путь из mutation-diff.mjs снять, а врезку из docs/TESTING.md («Выжил с нулём выполненных тестов — не находка») убрать вместе с ним.
3. Заодно посмотреть на RuntimeError: Test runner crashed — сейчас он не влияет на порог, но это тот же симптом.

[tihonove]

Разобрал оба симптома до конца. Диагноз другой, чем предполагался в постановке, и по одному из них апстрим уже в курсе.

1. «Выжил с нулём выполненных тестов»

Теряется не случайный прогон, а следующий за оборванным по bail. Stryker гоняет vitest с bail: 1, поэтому прогон убитого мутанта обрывается на первом упавшем тесте; следующий прогон в том же переиспользуемом воркере стартует и тихо не доезжает.

Инструментировал vitest-test-runner и снял состояние на каждом прогоне. Потерянный прогон выглядит так:

testIds: 833   уникальных файлов: 83
собрано файлов: 3, все в состоянии "run" (не pass/fail — не доехали)
тестов в них: 29, с результатом: 0
testNamePattern (77 249 символов) не совпал ни с одним: matchCount = 0
ошибок в errorsSet: 0, start() не бросал

А дальше — арифметика раннера: .filter((test) => test.result) выбрасывает всё без результата, список тестов пустеет, падений нет → Survived.

Оба потерянных прогона в инструментированном прогоне шли непосредственно за прогоном с fail: 1 (то есть за bail'нутым). Прогон по одному progressService.ts дважды подряд дал 5 и 2 «выживших» — все с testsCompleted: 0, все на разных мутантах. Это ровно та нестабильность, которую мы видели в #272.

Апстрим знает и разбирает то же самое: stryker-js#6073 (там независимо пришли к «losses cluster immediately after bail-aborted runs»), фикс предложен в #6146 — висит открытым с 26 июля.

disableBail симптом убирает, но ценой прогона всех покрывающих тестов на каждого мутанта: на progressService.ts вышло ~1 мутант в минуту вместо ~1 в секунду. Гейт из пятнадцати минут превратится в пару часов — не берём.

Вывод: наш обходной путь (точечная перепроверка) остаётся, пока #6146 не влит. Снимать — по нему.

2. Test runner crashed — это НЕ флак, и это наш код

Цепочка полностью:

1. Мутант if (entry.paneView === null) continue → if (false) в ViewsService.refreshTitleActions заставляет кинуть слушателя ViewTitleActionsContribution.
2. Слушателя зовут из queueMicrotask (коалесинг ContextKeyService.flush), поэтому исключение не принадлежит ни одному тесту: ни один тест не падает, vitest записывает unhandled error. В том прогоне их было 189.
3. Раз падений нет, vitest-runner уходит в ветку «ошибка вне прогона тестов» и зовёт errorToString на каждой.
4. errorToString делает String(error) — и падает. Vitest отдаёт не Error, а плоский клон (@vitest/utils/serialize.js: Object.create(null) + все функции по цепочке прототипов заменяются строками "Function<…>"). У объекта собственный toString — строка, а не функция, значит примитива из него не сделать:

> String({ toString: "Function<toString>" })
TypeError: Cannot convert object to primitive value

5. Воркер умирает, Stryker перезапускает его дважды и пишет RuntimeError.

Воспроизводится на 30 строках за 4 секунды (queueMicrotask + тест, который переживает исключение из него) — байт в байт та же ошибка. В апстриме такого тикета нет; текст с воспроизведением и патчем готов.

Патч в errorToString (try/catch → stack / name: message / Object.prototype.toString.call) проверен на воспроизводителе: вместо Test runner crashed мутант получает нормальный результат с сообщением, которое показывает место проблемы:

An error occurred outside of a test run: TypeError: Cannot read properties of null (reading 'accept')
    at .stryker-tmp/sandbox-…/src/notify.ts:74:16

3. Что эта история вскрыла у нас — две вещи

Дыра в гейте. Мутанты в статусе RuntimeError не входят в знаменатель балла, поэтому прогон с ними выходит нулём. В #272 так и было: 1 error, балл 100, гейт зелёный, мутант не проверен ничем. Починено: гейт смотрит не на код возврата, а на отчёт — упавшие перепроверяются точечно наравне с потерянными, а если раннер падает и там, гейт краснеет и печатает мутанта с причиной. Проверено end-to-end на том самом мутанте: первый прогон даёт «score 100 ≥ threshold 100», гейт всё равно уходит в перепроверку и заканчивает единицей.

Настоящий баг в проде. Исключение слушателя у нас не локализовано нигде: for (const listener of [...this.listeners]) listener() раскатан руками примерно в 30 файлах, ни один не ловит. Значит один кинувший слушатель (а) отменяет всех, кто за ним в Set, и (б) из микротаска/таймера роняет процесс целиком — обработчика uncaughtException у нас нет. В vscode ровно на это Emitter.fire заворачивает слушателя в try/catch и отдаёт ошибку в onUnexpectedError; у нас onUnexpectedError есть, но им пользуется только assertFn. Завёл отдельным тикетом.