Race condition between Webhook binary workflows renaming/deleting the ‘temp’ execution folder

快速结论：这个报错通常发生在自托管 n8n 使用 Filesystem 二进制数据模式、且多个 Webhook 请求并发触发同一工作流时：某个执行的清理钩子（restoreBinaryDataId）在另一个仍在运行的 Webhook 执行写入数据前就删除/重命名了 temp 执行目录，导致写入失败并抛出 ENOENT。优先排查是否处于 Filesystem Binary 模式，并升级到包含修复的 n8n 版本。

适用环境：Issue 已确认环境为自托管 n8n，使用 Postgres 数据库、Filesystem（文件系统）二进制数据模式（Binary mode 为 filesystem 而非 memory）。报告者测试版本包括 n8n 2.6.2、2.10.2；另有用户在 2.18.5 上复现。修复版本为 n8n 2.23.0（PR #31068）。

最快修复方案：升级到 n8n 2.23.0 或更高版本（该版本通过 PR #31068 修复了此问题）。

注意事项：不要单纯把二进制模式改回 Memory 当作正式修复——该行为只是规避，Issue 中未确认其为官方推荐方案。若暂时无法升级，可优先尝试减少同一 Webhook 路径的并发重叠，但这并非已验证的修复手段。升级前请备份 ~/.n8n 及二进制数据目录。

问题场景

在自托管 n8n 中，Webhook 节点同时接收多个请求（例如车牌识别摄像头短时间连续推送多张图片和 JSON），且工作流使用 Filesystem 二进制数据模式。并发执行时，一个执行在结束后运行的 restoreBinaryDataId 钩子会对 temp 执行目录做重命名/删除，与另一个仍在运行、正尝试将二进制文件写入 temp 的执行发生竞争，导致后者启动失败。报告中还提到相关 Issue #25064、#25065 同样与 temp 目录处理有关。

报错原文

ENOENT: no such file or directory, copyfile '/tmp/hu70lwzu09l256g0dd2vaaire' -> '/home/node/.n8n/binaryData/workflows/gFs1ZlonwqznIm0X/executions/temp/binary_data/edc295e7-d0ae-4b06-bb15-db780eb23260'

客户端侧可见的 Webhook 响应：

{"code":0,"message":"Workflow Webhook Error: Workflow could not be started!"}

并发执行时日志中还会出现类似警告：

Failed to restore binary data ID - No such file or dir

原因分析

Issue 中有用户明确指出根因是 FileSystemManager.rename() 内的 rm(tempDir, { recursive: true })：执行结束后的恢复/清理逻辑会递归删除整个 temp 目录，而此时另一个并发 Webhook 执行尚未把自己的二进制文件写入 temp，于是写入/复制失败。报告者推测即使修复了 #25064 的 temp 目录不总是被删除的问题，该竞争条件仍可能发生。该问题在切换到 Filesystem 作为默认 Binary 模式后开始出现，此前 Memory 模式下未遇到。

环境排查

确认 n8n 版本：受影响版本包括 2.6.2、2.10.2、2.18.5；请确认是否低于 2.23.0。
确认二进制数据模式（Binary mode）：是否为 filesystem 而非 memory。
确认部署方式：自托管，数据库为 Postgres（Issue 中已确认的环境）。
确认触发方式：是否存在同一 Webhook 路径的并发请求，尤其是带文件上传或 --data-binary 的图片请求与 JSON 请求混发。
确认 ~/.n8n（容器内为 /home/node/.n8n）下 binaryData/.../executions/temp 目录的读写权限与磁盘空间。
检查执行日志中是否有 Failed to restore binary data ID - No such file or dir 与上述 ENOENT 报错。

解决步骤

记录当前 n8n 版本和二进制数据模式，便于回滚对比。
升级 n8n 到 2.23.0 或更高版本。该版本已合并 PR #31068，Issue 由维护者确认修复并关闭。
若使用容器部署，拉取对应新版本镜像并重启服务；升级前备份 ~/.n8n 和数据卷。
升级后重跑 Issue 中的复现步骤（并发发送多张 example.jpg 与 TrafficFlow JSON 请求，循环运行脚本），观察是否仍出现 Workflow Webhook Error: Workflow could not be started!。
若暂时无法升级，可优先尝试降低同一 Webhook 的并发重叠（例如客户端侧限流或串行发送），并关注 #25064、#25065 的处理进展；这属于规避手段，不是已验证修复。

验证方法

按照 Issue 的复现脚本持续循环并发请求。修复前报告者在约前 50 次循环内即可复现；修复后其使用 PR #25541 测试最高 1000 次循环未再出现该竞争条件。因此可在升级到 2.23.0+ 后反复运行并发脚本，确认：

客户端不再返回 {"code":0,"message":"Workflow Webhook Error: Workflow could not be started!"}；
执行日志中不再出现上述 ENOENT 报错与 Failed to restore binary data ID - No such file or dir 警告；
所有并发的 Webhook 执行均成功，二进制附件未丢失。