Skip to content

Warm rector daemon trips ClassReflection bug on test classes — real fix behind PR #272 band-aid #273

Description

@fdaviddpt

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions