mirror of
https://github.com/langgenius/dify.git
synced 2026-10-04 13:47:55 +08:00
Charles YaoandClaude Opus 5
e2633ad6a0
Starting a NEW Build session on an app whose draft already holds a previous build's graph silently changed nothing and still reported "graph built". _already_present matches a create_node by node id ALONE, and the generator always emits node1, node2, ... So a new plan whose node2 is a parameter-extractor was filtered out against an existing node2 that is an llm: to_apply became empty, apply_repair([]) no-oped, change_set fell back to "graph built", and the session advanced to build.execution over an untouched canvas. Observed live -- the snapshot taken before apply was byte-identical to the draft after it, and the subsequent test run "passed" because it ran the OLD graph. The id filter itself is deliberate and stays: it is what makes a loop-back re-approve (continue_adjusting / revert) idempotent instead of raising on a colliding id. The guard therefore keys on built_node_ids, which names what THIS session built -- empty only on a session's first build, which is exactly the broken case. A loop-back still no-ops silently and advances. Does NOT clear the canvas on the user's behalf: that would destroy an existing workflow. It reports honestly and stays in plan_approval. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>