mirror of
https://github.com/langgenius/dify.git
synced 2026-10-04 13:47:55 +08:00
Charles YaoandClaude Opus 5
a96ed2d387
Code review finding: build.initial_plan was left in _WAITING with zero _ACTIONS_FOR entries but a handler still gated on find_resources. Since a waiting state settles the runner's advance loop (is_waiting(next_state) -> settled), continue_adjusting from build.review landed a session there with no button the FE could render and no action the handler would accept -- the loop-back could never advance. Reclassify build.initial_plan as working (state.py _WORKING, not _WAITING): it is now a genuine pass-through step, matching build.test_and_repair / build.publish / build.governance_feedback. handle_initial_plan drops its find_resources gate and runs resource discovery unconditionally on entry; the runner drives it with the action already consumed and falls straight through to build.resource_recommendation within the same advance() call. Removed the now-stale BUILD_INITIAL_PLAN entry from service.py's _BACKEND_ACTIONS_FOR (no action to gate on any more) and the compensating exemption it required in test_every_backend_waiting_action_has_a_ui_path (the invariant now holds with no special case). Added a state-classification test (test_build_initial_plan_is_working_not_ waiting) and an end-to-end regression driving the Runner from build.review through continue_adjusting with no find_resources action ever sent (test_continue_adjusting_reaches_resources_without_find_resources_action), which is the scenario this fix exists to unwedge. Fixed the two existing idempotency flow tests that asserted the old (broken) two-step loop-back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>