[ondrejmirtes]

A file changed and changed back between two polls of the file monitor looks unchanged to it. If an analysis read the file in between, nothing starts another one, and the errors of the code that existed only during the analysis stay until the next edit.

HashingFileMonitor polls once a second, so an undo within a second is enough. It is what Windows always uses, and what Linux and macOS use without FFI.

The change

The result cache already finds these files when it saves, and records them to be analysed again (#6377). Only nothing started that analysis.

• FixerWorkerRunner asks ResultCacheManager::getFilesChangedDuringAnalysis() after saving and sends filesChangedWhileAnalysed when there are any.
• FixerApplication treats that like a change its file monitor saw. It goes through the same poll loop, so pausing and waiting for a burst of changes to end apply to it, and an analysis already about to start clears it instead of adding one more.

Something writing to the analysed files during every analysis, like a generator in a bootstrap file, would keep the analyses going. An analysis started only because of this report therefore does not start another one; a change the monitor sees resets that. The cost is that a second change-and-revert during that one follow-up analysis is missed.

Testing

No unit test covers FixerApplication, the regression test is the existing visual spec file changed and changed back while it is analysed. Run on macOS with PHPSTAN_DISABLE_NATIVE_FILE_MONITOR=1:

	passed
spec without this change	0 of 8 (7 errors instead of 6, for the whole 30 s wait)
spec with this change	5 of 5
spec without this change, revert delayed by 1.5 s, so that a poll sees it	8 of 8
full suite, hashing, light project	119 of 120
full suite, FSEvents, light and dark	235 of 240, 3 skipped by design

The failure in both suites is level changed in the config, which is unrelated: initialData.ruleLevel is sent only once, at startup. Screenshots were not compared on macOS, their baselines are rendered on Linux.

A report arriving while PHPStan Pro is paused waits for the resume, because the poll loop returns early while paused. That comes from reading the code, no spec covers it.

phpstan/phpstan-fixer#310 runs the visual tests with both monitors in CI, and adds a spec for the loop above that fails with the guard removed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SLV3fAj54R19CE8XoFyu9Z