openrewrite / openrewrite/rewrite
Kotlin recipe DSL: scan/generate phases silently dropped in K2 synthesis
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 3.7k
- Forks
- 570
- Avg merge
- 13h 12m
- Merged PRs (30d)
- 261
Description
What's wrong
In the rewrite-kotlin K2 compiler plugin, imperative recipe(...) declarations that use a scanning or generating phase are silently reduced to an edit-only recipe. The scan/generate phases are dropped during synthesis, so at runtime the recipe behaves as if those phases were never written.
There is no error, warning, or diagnostic — the recipe compiles cleanly and runs, it just doesn't do what the source says.
Affected recipe shapes
scan { }.generate { }— emits nothing. The scanner never runs andgenerateis never called, so no source files are produced.- bare
generate { }— same: the generated output is lost. scan { }.edit { }— the edit runs, but against a fresh/empty accumulator because the scanner never registered. Any edit that depends on scanned state behaves as though nothing was scanned.
Edit-only recipes (edit { }, declarative rewrite { } to { }) are unaffected.
Symptoms folks are seeing
- A
scan { }.generate { }recipe produces no output at all — no new files, no changes — with no indication of why. - A
scan { }.edit { }recipe makes no changes (or wrong changes), because the edit sees an empty accumulator instead of the state the scan phase was supposed to collect. - Everything looks healthy: the recipe compiles, the plugin accepts the shape, tests that only assert "no crash" pass. The failure is entirely silent and only visible by noticing the expected output is missing.
Why it's easy to miss
The DSL checker accepts these shapes as valid, and the synthesized recipe is a perfectly runnable object — it's just the wrong kind of recipe (a plain edit recipe rather than a scanning one). Because there's no diagnostic, the only signal is the absence of expected results, which is easy to attribute to the recipe logic rather than to the plugin silently discarding phases.
Expected behavior
An imperative recipe that declares a scan/generate phase should retain that phase at runtime — the scanner should run, its accumulator should be visible to the generate/edit phase, and generated files should be emitted — matching the behavior of the equivalent hand-written ScanningRecipe.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the rewrite-kotlin K2 compiler plugin and trace synthesis of imperative recipe(...) declarations, comparing scan/generate shapes with edit-only recipes. Verify that scan/generate phases survive into the runtime recipe, that the accumulator reaches later phases, and that generated files are emitted; cover all three affected shapes with regression tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100