Fix --only runs caching files as unchanged, hiding pending changes from full runs by SanderMuller · Pull Request #8029 · rectorphp/rector-src

SanderMuller · 2026-06-10T19:22:57Z

Problem

A file that is clean under one rule is not necessarily clean under all rules. A run with --only SomeRule (or --only-suffix) caches such files as unchanged, so the next full run silently skips their pending changes until --clear-cache.

Repro on main:

rector process --dry-run --clear-cache --only "Rector\DeadCode\Rector\ClassMethod\RemoveEmptyClassMethodRector" on a file with an always-true if → clean under that rule, file gets cached
rector process --dry-run → reports [OK] Rector is done! instead of the pending RemoveAlwaysTrueIfConditionRector change

Fix

Skip the unchanged-files cache write on selective runs. One guard in ApplicationFileProcessor.

Test

Unit test on ApplicationFileProcessor::processFiles(): an --only / --only-suffix run must leave the file uncached, a plain dry-run caches it (control test). The two guard tests fail on main, pass with the fix.

Split out of #8028 as a standalone pre-existing bugfix, as discussed with @TomasVotruba.

🤖 Generated with Claude Code

A file clean under one rule is not necessarily clean under all rules. An --only run cached such files as unchanged, so the next full run silently skipped their pending changes until --clear-cache. Covered by a new e2e scenario that fails on main: an --only run followed by a full run must still report the change pending under the other rule. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The cache only checked each file's own content, so a clean file stayed skipped on warm runs even when one of its dependencies changed, e.g. a parent class method gaining a return type that lets a child file infer its own. A fresh run reports the new change, a warm run misses it. PHPStanNodeScopeResolver now records each file's dependencies during scope resolution using PHPStan's own DependencyResolver. Cache entries store the file's own hash plus one hash per dependency, all re-validated on load; legacy string entries self-upgrade on the next write. A failed capture skips caching entirely rather than caching a partial set. To keep capture cheap, only nodes whose resolver branch can produce dependencies are resolved, and native function calls are skipped via NativeFunctionCallAnalyzer, avoiding PHPStan's function signature map load. Two tripwire tests pin the external assumptions: one parses the bundled DependencyResolver and fails if its branch set changes on a PHPStan bump, the other asserts native function reflections stay fileless. Selective runs (--only, --only-suffix) bypass the cache write, same guard as rectorphp#8029. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

TomasVotruba · 2026-06-10T19:34:01Z

Thanks for the fix 👍

e2e seems heavy for such a verfication.
Is there any way to test this via unit test? Should be some simple operation to check.

ApplicationFileProcessor::processFiles() with no rules registered reaches the cache-write branch directly, so the guard is testable without an e2e project: an --only / --only-suffix run must leave the file uncached, a plain dry-run caches it. Fails on main, passes with the fix. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

SanderMuller · 2026-06-10T19:44:46Z

Good call — replaced the e2e with a unit test, PR is now 81 lines total.

ApplicationFileProcessor::processFiles() with no rules registered reaches the cache-write branch directly, so no e2e project is needed: an --only / --only-suffix run must leave the file uncached, a plain dry-run caches it (control test). Verified the two guard tests fail on main and pass with the fix. Runs in ~0.6s.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The cache only checked each file's own content, so a clean file stayed skipped on warm runs even when one of its dependencies changed, e.g. a parent class method gaining a return type that lets a child file infer its own. A fresh run reports the new change, a warm run misses it. PHPStanNodeScopeResolver now records each file's dependencies during scope resolution using PHPStan's own DependencyResolver, the same engine behind PHPStan's result cache. Cache entries store the file's own hash plus one hash per dependency, all re-validated on load; legacy string entries self-upgrade on the next write. A failed capture skips caching entirely rather than caching a partial set. Function calls memoize their dependency files per resolved name, as signature dependencies are identical at every call site. Selective runs (--only, --only-suffix) bypass the cache write, same guard as rectorphp#8029. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

TomasVotruba · 2026-06-19T10:30:25Z

I'd love to merge this one. @samsonasik Can you check if its ready?

samsonasik · 2026-06-19T10:33:46Z

@TomasVotruba seems ok, the drawback is with this change, the --only and --only-suffix will not have cache on run same command multiple times

TomasVotruba · 2026-06-19T10:39:07Z

@samsonasik Hm, that would be a bit counter productive. But cost of having full cache cleared on single --only use is a bigger drawback. If I understand this change correctly.

samsonasik · 2026-06-19T10:44:19Z

Yeah, I tried to handle this in the past, but it not works well as expected, as the cache hit will back and forth, see old PR:

[Configuration] Make --only to force clear cache to ensure next normal run start from fresh state #7641

TomasVotruba · 2026-06-19T10:51:36Z

In that case, I'll go with this approach, seems more intuitive.

TomasVotruba · 2026-06-19T10:52:28Z

Thank you @SanderMuller 👍

rectorphp#8029 stopped caching selective runs to fix full-run poisoning (a file clean under one rule was cached as clean for all). That also removed the cache on repeated --only / --only-suffix runs — a drawback raised in that thread, and what rectorphp#7641 set out to solve. Scope the per-file cache key by the active rule selection instead. Selective and full runs then use distinct, coexisting cache entries: a repeated --only run is served from cache, a full run is never poisoned by it, and nothing is cleared, so there is no back-and-forth thrash (the behaviour that closed rectorphp#7641). The scope is set in both run() and processFiles() because parallel workers invoke processFiles() directly via WorkerCommand, bypassing run(), and must write entries under the same scope the main process reads.

SanderMuller · 2026-06-21T16:45:20Z

Yeah, I tried to handle this in the past, but it not works well as expected, as the cache hit will back and forth, see old PR:

[Configuration] Make --only to force clear cache to ensure next normal run start from fresh state #7641

Thanks for the pointer, can you see if #8075 got this working?

SanderMuller mentioned this pull request Jun 10, 2026

Fix unchanged-files cache missing changes induced by changed dependencies #8028

Closed

samsonasik reviewed Jun 10, 2026

View reviewed changes

Comment thread tests/Application/ApplicationFileProcessor/Source/CleanFile.php

fix: PSR-4 compliant test fixture name and namespace

5acfcc3

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

TomasVotruba requested a review from samsonasik June 19, 2026 10:29

TomasVotruba merged commit b31a1e5 into rectorphp:main Jun 19, 2026
64 checks passed

SanderMuller mentioned this pull request Jun 21, 2026

Cache --only / --only-suffix runs under a rule-scoped key #8075

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix --only runs caching files as unchanged, hiding pending changes from full runs#8029

Fix --only runs caching files as unchanged, hiding pending changes from full runs#8029
TomasVotruba merged 3 commits into
rectorphp:mainfrom
SanderMuller:fix/only-rule-cache-poisoning

SanderMuller commented Jun 10, 2026 •

edited

Loading

Uh oh!

TomasVotruba commented Jun 10, 2026

Uh oh!

SanderMuller commented Jun 10, 2026

Uh oh!

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

samsonasik commented Jun 19, 2026 •

edited

Loading

Uh oh!

TomasVotruba commented Jun 19, 2026 •

edited

Loading

Uh oh!

samsonasik commented Jun 19, 2026

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

SanderMuller commented Jun 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

SanderMuller commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Test

Uh oh!

TomasVotruba commented Jun 10, 2026

Uh oh!

SanderMuller commented Jun 10, 2026

Uh oh!

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

samsonasik commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TomasVotruba commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samsonasik commented Jun 19, 2026

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

Uh oh!

TomasVotruba commented Jun 19, 2026

Uh oh!

SanderMuller commented Jun 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

SanderMuller commented Jun 10, 2026 •

edited

Loading

samsonasik commented Jun 19, 2026 •

edited

Loading

TomasVotruba commented Jun 19, 2026 •

edited

Loading