Dify 批量处理只失败几条，怎样留下可重跑清单

Dify批量处理只失败几条时，应该按每条数据的稳定编号保留结果，生成可重跑清单，而不是把整批重新执行。尤其是创建工单、发送通知或写入业务系统，整批重跑可能重复操作。本文设计十条合成数据的恢复记录，重点是部分失败后的状态管理，不是迭代节点入门。

每条数据先有自己的身份

合成批次BATCH-DEMO-01包含ITEM-01到ITEM-10，任务是把设备异常摘要写成待审核工单。每条输入都有稳定编号和内容校验值，批次另有运行标识。输入顺序只是显示顺序，不能作为唯一身份，因为失败项筛出后数组位置会改变。

输出应保留项目编号、处理状态、业务回执、尝试次数、错误类别和最近执行时间。状态至少区分成功、明确失败和结果未知。本文字段是恢复台账的自定义契约，不是Dify原生输出格式，需要在工作流或接入服务中实现。

附件提供十条合成结果，其中六条成功、两条明确失败、一条结果未知、一条输入不合法；同时列出可重跑判断。这些是演示状态，真实平台结果列应由执行日志填入，不能当成已经跑过十条数据。

不要只保留成功数组

官方迭代节点支持按数组逐项执行，错误处理方式依赖目标版本。选择忽略或移除异常输出时，尤其要确认失败项目是否仍有可定位记录。若输出数组只剩成功项，按位置与原输入拼接会造成错位。

可以让每次迭代返回包含项目编号的结果对象，或在接入层按项目记录状态。即使某项抛错，也要能从运行证据判断它对应哪条输入。若平台错误分支不能满足要求，补一层任务台账通常比猜输出顺序可靠。

并行执行时，完成顺序可能不同于输入顺序。汇总时按稳定编号合并，并检查是否缺号、重号或出现未知编号。十条输入最终应能解释十条状态，不能只说“成功八条”却不知道另外两条在哪里。

先判断能不能重跑

网络临时错误、提供方限流可能适合重试；缺必填字段需先修数据；权限错误需先修授权；业务拒绝需业务人员决定。结果未知尤其需要谨慎，调用超时不代表工单没创建，应先通过幂等键或外部查询确认。

演示中ITEM-07是限流，可在策略允许时重跑；ITEM-08是解析失败，需要修正内容；ITEM-09超时但回执未知，应先查业务系统；ITEM-10缺设备编号，先补输入。四者不能都放进同一个自动重试队列。

重跑清单保留原批次、原项目编号、上次尝试和新的内容校验值。若用户修过数据，应形成新输入版本，保留与原失败的关联。否则后续看到成功结果，也无法确认它处理的是哪一份材料。

幂等与落盘顺序

创建工单前，由业务服务按稳定任务键判断是否已有记录；已有时返回原回执，不重复创建。成功写入回执后再把台账标记成功。若先标成功再写业务系统，进程中断可能形成假成功；若只写业务系统不记回执，下次重跑又可能重复。

并不是所有业务系统都提供幂等功能。缺少时，应在接入层补任务锁、唯一约束或人工核对策略，并说明不能保证的范围。Dify迭代节点的错误处理选项本身不等于业务幂等。

重跑后做差异核对

只选择已确认可恢复的项目，保持未变项目不再调用。完成后把新结果合并回原台账，保留所有尝试记录。检查成功项目的外部回执唯一、失败项目原因明确、未知项目有跟进人，并确认没有产生重复工单。

测试至少包含一次部分失败、一次客户端中断和一次进程恢复。可以用模拟业务服务记录调用次数，验证相同任务键是否只产生一个业务对象。本文未执行目标实例实验，附件中的回执均以DEMO标识显示。

最终交付物应是一个可解释的批次，而不是只剩“成功输出”的漂亮数组。业务负责人需要知道哪些已经完成、哪些可以再跑、哪些必须人工处理，技术人员则需要能够从每条状态回到原请求和执行证据。

重跑结果合并时不能覆盖原始错误。保留每次尝试的开始结束、输入版本和业务回执，当前状态只是这组历史的汇总。这样当第二次成功却出现重复对象时，能够查到哪一次产生了副作用。还应设置人工停止条件，持续出现同类授权或契约错误时暂停批次，避免自动重试消耗更多资源。重跑清单最好由状态规则生成，再由有权限的人确认执行范围，不能直接把所有非成功行交给模型自行选择。

官方依据：Dify Iteration节点说明逐项执行；预定义错误处理说明不同异常输出处理方式。请在目标版本确认选项与返回行为，台账与幂等需另行实现。

可下载本文合成样例与记录表，附件里的数据只用于演示核对方法，请在副本中填写目标环境结果。更多背景可看专题与相关原理及交付说明。需要把这套核对接进已有业务系统，可带上脱敏材料、当前版本与失败记录，通过定制咨询讨论范围；集成商可查看系统集成协作。