fix(devloop): recompile the app when a reactor sibling leaves the loop - #25465
fix(devloop): recompile the app when a reactor sibling leaves the loop#25465tltv wants to merge 1 commit into
Conversation
The module set is derived from the app's resolved classpath, so dropping a sibling dependency removes both the sibling's target/classes and the sibling itself from the loop. That module-set change rebuilt Compile, whose constructor re-seeded compiledAgainst from the project as it now stood - overwriting the app's classpath baseline with the already-moved classpath. classpathForced then saw no movement and forced no recompile, so the apply fell through to the drift restart and reported Stable while the page broke with ClassNotFoundException. An external jar was unaffected: it changes no module, so the baseline survived and the forced recompile fired. Compile now takes the outgoing baseline and carries compiledAgainst over for every module still in the loop. The app module is recompiled whole, and javac's diagnostic ends the apply as Failed before the restart leg runs. Only the classpath baseline is carried; per-file stamps still start afresh, as they describe a different build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Carrying the outgoing baseline reroutes a sibling drop from a silent restart to a compile failureflowchart LR
subgraph Before
direction TB
B1["new Compile(project)"] -->|re-seeds baseline from moved classpath| B2["classpathForced() sees no movement"]
B2 -->|no forced recompile| B3["classpathDrift() escalates to restart"]
B3 -->|next page load| B4["ClassNotFoundException"]
end
subgraph After
direction TB
A1["new Compile(project, current)"]:::changed -->|carries previous compiledAgainst| A2["classpathForced() forces app sources"]
A2 -->|recompiles app module| A3["javac diagnostic"]
A3 -->|ends apply before restart leg| A4["Failed"]
end
Before ~~~ After
classDef changed stroke:#c9a227,stroke-width:3px
The figure shows Diagram Bot draws the mechanism this pull request touches; it does not review the change. Verify it against the diff.
|
|
1 participant
The module set is derived from the app's resolved classpath, so dropping a sibling dependency removes both the sibling's target/classes and the sibling itself from the loop. That module-set change rebuilt Compile, whose constructor re-seeded compiledAgainst from the project as it now stood - overwriting the app's classpath baseline with the already-moved classpath. classpathForced then saw no movement and forced no recompile, so the apply fell through to the drift restart and reported Stable while the page broke with ClassNotFoundException. An external jar was unaffected: it changes no module, so the baseline survived and the forced recompile fired.
Compile now takes the outgoing baseline and carries compiledAgainst over for every module still in the loop. The app module is recompiled whole, and javac's diagnostic ends the apply as Failed before the restart leg runs. Only the classpath baseline is carried; per-file stamps still start afresh, as they describe a different build.