Parallel fail-fast leaves collateral node failures unattributed and stale

快速结论：该报错通常出现在 Dify 工作流并行分支启用了 fail-fast、其中一个分支致命失败时；图级失败信息只有错误文本，无法标明触发失败的节点，被 fail-fast 终止的兄弟节点（仍在运行或重试）可能残留在实时 Tracing 与画布上，持久化记录也无法说明终止原因。优先排查并行 fan-out 结构、fail-fast 配置以及 graphon 层是否已发布致命节点执行标识。

适用环境：Dify 自托管源码部署，版本为 main（Issue 描述为在提出修复前的源码分支上复现）。Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息。

最快修复方案：暂无确认的一步修复方案。该问题依赖配套的 langgenius/graphon#220：graphon 需先保留并发布致命节点执行身份，Dify 才能持久化并在界面中呈现因果归属。可优先尝试升级到包含该修复的 graphon 与 Dify 版本，并重新运行复现工作流。

注意事项：Issue 未给出已验证的补丁或配置改法；在 graphon 修复落地前，仅调整 Dify 侧可能无法消除残留状态。工作流运行结束后以持久化 trace 为准，不能仅凭实时面板判断节点最终状态。

问题场景

在 Dify 自托管源码环境中创建含并行 fan-out 的工作流：开始节点分出多个并行分支，其中一个分支以 fail-fast 方式致命失败，同时至少一个兄弟节点仍在运行，可选另一个兄弟节点处于重试状态。从 Test Run 面板运行后，查看实时 Tracing 面板、画布和持久化运行 trace。最小复现可用一个立即失败的 HTTP 节点加两个同属兄弟分支的慢速 LLM 节点。

报错原文

Parallel fail-fast leaves collateral node failures unattributed and stale

原因分析

根据 Issue 描述，图级失败对象只携带错误文本，缺少致命节点执行的身份信息，因此 Dify 无法区分真正的失败源节点与被 fail-fast 终止的兄弟执行。可能原因包括：graphon 在发布致命失败前未保留节点执行标识（对应 langgenius/graphon#220）；Dify 侧对被终止的并发执行未写入带因果元数据的失败状态；实时 Tracing 面板与画布未在工作流结束后与持久化的终端节点状态对齐，导致仍在运行或重试的兄弟节点显示为过期状态。

环境排查

确认 Dify 部署方式为 Self Hosted (Source)，并记录实际使用的分支与提交。
确认工作流是否存在并行 fan-out，以及哪个分支配置了 fail-fast。
确认所用的 graphon 版本是否已包含 langgenius/graphon#220 的修复。
对照 Test Run 面板的实时状态与持久化运行 trace，确认残留节点范围。
Issue 未提供 Python、CUDA、显卡及依赖版本信息，无需据此排查。

解决步骤

按 Issue 的最小复现构建工作流：一个立即失败的 HTTP 节点，以及两个慢速 LLM 兄弟节点，其中失败分支启用 fail-fast。
运行工作流，记录图级失败信息中是否包含具体节点执行身份。
检查被终止的兄弟节点在持久化 trace 中是否记为 failed，并带有指向源节点的因果元数据。
对比实时 Tracing 面板与画布，确认工作流结束后节点状态是否与持久化终端状态一致。
如确认图级失败仅有错误文本，则属于本 Issue 描述的问题；可优先尝试升级到包含 graphon 修复的版本，因为 Dify 侧需要 graphon 先发布致命节点执行身份。
若升级后仍复现，携带 Dify 版本、graphon 版本、工作流结构与复现附件提交到原 Issue。

验证方法

重新运行同一工作流后，图级失败应能定位到确切的节点执行；被 fail-fast 终止的兄弟节点应以 failed 持久化，并带有说明源节点的因果元数据，界面呈现为“因其他节点失败而终止”而非自身报错；工作流结束后，实时 Tracing 面板与画布应与持久化终端节点状态一致，不再出现残留的运行或重试状态。