Background
PR #272 stopped a poisoned-cache symptom: mcp-rector-warm's long-lived daemon intermittently emits rector's own System error: "ClassReflection must be resolved for class XTest" on test classes, and that failure was being cached + replayed (2100 poisoned entries found).
PR #272 papers over it at two layers (drop System error: in the rector-mcp adapter; never cache non-deterministic engine failures). That's correct — an engine glitch is not a code finding — but it's a band-aid. The warm daemon still hits the reflection bug; we just stop surfacing/caching it.
Root cause (as far as proven)
- Plain
rector CLI (fresh boot) reflects the same test file clean (exit 0).
- The warm in-process container (
RectorRunner, reused across calls) intermittently fails to resolve a ClassReflection for the analyzed test class. It's warm-process-state dependent, not file dependent — cold-first and warm-repeat both passed in controlled runs; the live failure only reproduced from a deeply-warm daemon, then got frozen into the content-hashed cache.
- Most likely: BetterReflection in the warm process takes an 'already known' path for a class it can't resolve from rector's scoped source locator. Exact trigger not pinned — needs a deterministic repro inside the warm process (run rector
--debug in the embedded container and capture the stack).
What a real fix looks like
Make the warm daemon's reflection scope match a cold CLI boot so test classes resolve — e.g. ensure the test autoload paths / reflection provider are warmed the same way, or reset the relevant reflection state per call. Lives in the mcp-rector-warm repo, not here.
Acceptance
- Deterministic repro of the warm-only
ClassReflection failure.
- Warm daemon returns the same result as
rector CLI for test classes (no System error:).
- Once fixed upstream, the adapter's
System error: suppression can stay as defense-in-depth but is no longer load-bearing.
Ref: PR #272.
Background
PR #272 stopped a poisoned-cache symptom:
mcp-rector-warm's long-lived daemon intermittently emits rector's ownSystem error: "ClassReflection must be resolved for class XTest"on test classes, and that failure was being cached + replayed (2100 poisoned entries found).PR #272 papers over it at two layers (drop
System error:in the rector-mcp adapter; never cache non-deterministic engine failures). That's correct — an engine glitch is not a code finding — but it's a band-aid. The warm daemon still hits the reflection bug; we just stop surfacing/caching it.Root cause (as far as proven)
rectorCLI (fresh boot) reflects the same test file clean (exit 0).RectorRunner, reused across calls) intermittently fails to resolve aClassReflectionfor the analyzed test class. It's warm-process-state dependent, not file dependent — cold-first and warm-repeat both passed in controlled runs; the live failure only reproduced from a deeply-warm daemon, then got frozen into the content-hashed cache.--debugin the embedded container and capture the stack).What a real fix looks like
Make the warm daemon's reflection scope match a cold CLI boot so test classes resolve — e.g. ensure the test autoload paths / reflection provider are warmed the same way, or reset the relevant reflection state per call. Lives in the
mcp-rector-warmrepo, not here.Acceptance
ClassReflectionfailure.rectorCLI for test classes (noSystem error:).System error:suppression can stay as defense-in-depth but is no longer load-bearing.Ref: PR #272.