mirror of
https://github.com/langgenius/dify.git
synced 2026-10-04 13:47:55 +08:00
Charles YaoandClaude Opus 5
6877532f8e
_repair_is_repeating could never fire in production. _note_repair_error counted repeats by exact string equality on diagnosis.root_cause, which is LLM prose regenerated on every diagnosis call. Observed live across four turns of one session: same failure, reworded every time, one turn switching to Chinese. Equality therefore never held, repair_attempts reset forever, and the guard was unreachable -- that session burned 9 failed verify runs and 8 repair approvals with the guard in place. The call site's own comment reads "ESQ1-285 burned nine approvals this way, ESQ1-290 six". The reproduction burned nine again. Key on the ENGINE's output instead: _failure_signature(run) returns the first failed node's id plus its error text (whitespace-collapsed), falling back to the launch error, and "" when the run identifies nothing -- so two unknown failures never compare equal. Why the existing tests passed while production was broken: every one of them fed _note_repair_error the SAME literal string twice, and StubAgent.diagnose always returns one fixed root_cause. They encoded the premise that is false in production. The new handler-level test drives three turns with an agent that rewords its root_cause each call while the engine fails identically, and fails against the old implementation with repair_attempts == 0. last_repair_error now holds that signature rather than prose. It was never displayed -- its only use was this comparison. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>