Dify 0.6.14 的工作流节点报 variable not found

事情本身不复杂，线索都在日志里。Dify 0.6.14 用 docker compose 部署，工作流里加了一个代码节点，下游写 {{#code_1.result#}} 取输出，运行报 variable not found，同样写法在 0.6.9 上是通的。

第一反应是「变量选择器里存的是旧版结构，升级后没有迁移」，验证下来不成立。

排查方向其实有限，先把可能性排一排。代码节点的输出在 0.6.14 改成统一包一层，旧引用路径取不到键。另一种情况是节点 id 被重新生成，上游引用还指向旧 id。

不容易想到的是，代码节点返回的不是 dict，前端生成不出可引用字段。

第一件事是把草稿结构拉出来核对节点 id

curl -s -H "Authorization: Bearer $DIFY_KEY" http://127.0.0.1/v1/workflows/draft | jq '.graph.nodes[].id'

代码节点统一返回 dict 并带固定键

python -c "def main(x):return {'result':x}"

接着核对连线的源节点是否与当前 id 一致

curl -s -H "Authorization: Bearer $DIFY_KEY" http://127.0.0.1/v1/workflows/draft | jq '.graph.edges[].source'

等前面都确认过，再改完在工作流里整体跑一次

curl -X POST http://127.0.0.1/v1/workflows/run -H "Authorization: Bearer $DIFY_KEY" -H "Content-Type: application/json" -d '{"inputs":{},"response_mode":"blocking","user":"qa"}'

恢复的判定其实很直接。运行返回 status 为 succeeded，下游节点能取到代码节点的 result 字段，日志里不再出现 variable not found。

这里还有个坑。升级前把工作流导出成 yml 备份，变量路径这类结构在次版本之间改过不止一次。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。