mirror of
https://github.com/langgenius/dify.git
synced 2026-10-04 13:47:55 +08:00
Charles YaoandClaude Opus 5
f665ddcec2
Code review finding: handle_goal_analysis built its own ProgressReporter (build-review-requirements/build-draft-plan) and finish()ed it, then tail-called _discover_and_offer_resources, which built a SECOND reporter under the SAME env.operation_id. ProgressReporter's revision counter starts at 0 per instance, so the second reporter's activate/finish calls restarted revision at 1 -- two progress events with revision 1 (and 2, and 3) under one operation_id. contract.py's ProgressEventData docstring states revision is monotonic within an operation_id; every other handler across the three handler files uses exactly one reporter per step -- this was the sole exception, on the most-travelled build path. Fix: _discover_and_offer_resources now takes an optional `progress` parameter. handle_goal_analysis passes its live (still-open) reporter through instead of finishing it early; the helper adds the discovery steps onto that SAME reporter via add_steps() and is the one that finish()es it. handle_initial_plan (the continue_adjusting/retry_after_revert loop-back, which has no reporter of its own -- a separate CAS commit/operation) still gets progress=None and the helper builds a fresh one, unchanged. Added test_submitting_requirements_progress_is_one_operation_with_monotonic_ revisions: drives the real Runner with submit_requirements, captures every emitted ProgressEventData, and asserts a single operation_id with strictly increasing, non-repeating revisions across all four progress steps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>