openrewrite / openrewrite/rewrite

Kotlin recipe DSL: scan/generate phases silently dropped in K2 synthesis

Open
#8,657 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

kotlin recipe
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 and generate is 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.