mirror of
https://github.com/langgenius/dify.git
synced 2026-10-04 13:47:55 +08:00
Charles YaoandClaude Opus 5
9a910f27e7
Four findings from the whole-branch review, all in the repair loop: I1 -- repair_attempts/last_repair_error were added to the context and to serde but not to recovery._reset_working_fields (which clears eleven sibling fields) nor to the re_fix/restart re-plan branches, so a fresh build could inherit repair_attempts >= the ceiling and decline a repair on its FIRST failure. They are cleared with their siblings now. The guard also ANDed a monotonic counter with a consecutive-error test, so A -> B -> B tripped it although B had survived one repair. _note_repair_error now makes the counter mean what the docstring says: consecutive repeats of ONE error, reset when the error changes. I2 -- the repeated-failure return dropped run/run_id_sink, so repo.save_run never ran while fc.verify_run_id already pointed at that run: a dangling pointer and the third failing run lost from the debug export. I3 -- ESQ1-291's empty-staged-repair guard existed in Build only. Edit's model-config branch GUARANTEES an empty staged repair and routes to a state whose approve applied it blindly; handlers_fix.handle_apply had the same shape. Both are guarded now, reusing Build's notice. I5 -- apply_repair re-validates intents against the draft as it is NOW, so a dotted path that was applicable at propose time can raise ValueError at approve time. Uncaught at all three approve sites, it reached the runner and drove the session to FAILED -- the exact ESQ1-271 outcome this branch set out to remove. Each site now degrades to a "Couldn't apply the fix" error card naming the reason and clears the staged repair (engaging the I3 guard). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>