Sandbox “no space left on device” — 6,543 failed workflow runs and a full hour of failures

快速结论：“no space left on device” 通常发生在 Dify Cloud 上运行含 Python Code 节点的已发布工作流时，说明 Sandbox 容器内的临时目录被写满，导致 Python 代码节点无法创建临时 .py 文件。优先排查 Sandbox 的临时存储容量与临时文件清理机制。

适用环境：Dify Cloud（Cloud version），通过 POST https://api.dify.ai/v1/workflows/run 调用已发布工作流；问题由 Dify Cloud 侧 Sandbox 基础设施触发，本地无法复现存储耗尽。

最快修复方案：暂无确认的一步修复方案。官方已在 dify-sandbox PR #290 中修复该问题，Cloud 用户等待平台侧部署即可；自托管用户可优先尝试跟进该 PR 对应的修复。

注意事项：该 Issue 无法按需复现，因为 Sandbox 基础设施由 Dify Cloud 托管。评论中仅说明已通过 PR 修复，未给出可自行执行的清理命令或配置项，不要臆造清理脚本或目录调整方案。

问题场景

用户在 Dify Cloud 上运行已发布的 Dify 工作流，工作流中包含 Python Code 节点，并通过 POST https://api.dify.ai/v1/workflows/run 调用。在 2026 年 9 月 14 日 12:43 至 14:01 UTC 的正常影子流量期间，Sandbox 反复执行失败，导出日志中包含 6,543 条相同报错；其中 13:00–14:00 UTC 期间全部 4,953 次工作流运行均失败，约 14:01 UTC 后恢复成功处理。

报错原文

Got error code: -500.
Got error msg: open /var/sandbox/sandbox-python/tmp/<uuid>.py:
no space left on device

原因分析

最可能的原因是 Dify Sandbox 用于存放 Python 执行临时文件的目录 /var/sandbox/sandbox-python/tmp/ 空间耗尽。每次执行 Python Code 节点时，Sandbox 需要在该目录写入一个以 uuid 命名的 .py 临时文件；当底层存储写满后，文件创建失败并返回 -500。结合 Issue 表现为持续约一小时的大批失败后自行恢复，可推测为 Sandbox 临时存储达到上限且未能及时自动清理临时执行文件；具体根因以官方在 dify-sandbox PR #290 中的修复为准。

环境排查

确认使用的是 Dify Cloud 还是自托管部署，本 Issue 确认发生在 Dify Cloud（Cloud version）。
确认调用方式为 POST https://api.dify.ai/v1/workflows/run，且触发失败的工作流包含 Python Code 节点。
若为自托管，需检查 dSYM/Sandbox 相关容器映射的存储卷剩余空间，以及 /var/sandbox/sandbox-python/tmp/ 所在分区的可用容量。
检查 Sandbox 是否具备临时文件自动清理机制，以及短时间内是否有大量 Python Code 节点请求集中执行。
Issue 未提供 Python、CUDA、PyTorch、显卡或具体依赖版本信息，无需据此推断。

解决步骤

Cloud 用户：确认报错信息是否为 no space left on device 且路径指向 /var/sandbox/sandbox-python/tmp/，以匹配本 Issue 场景。
Cloud 用户：由于 Sandbox 基础设施由 Dify Cloud 管理，无法本地修复，建议保留受影响的 run ID 与清理后的日志，等待平台侧修复。
自托管用户：可优先尝试跟进官方修复 PR：https://github.com/langgenius/dify-sandbox/pull/290，按该 PR 的改动更新 Sandbox 相关实现。
自托管用户：在无法立即升级的情况下，可优先尝试检查并清理 Sandbox 临时目录占用，或扩大该目录所在存储卷容量，并确保有定期清理机制。（此项为可优先尝试的排障方向，Issue 中未验证。）

验证方法

重新调用包含 Python Code 节点的已发布工作流，确认返回中不再出现 -500 与 no space left on device 报错，且 Python 代码节点能正常生成临时文件并完成执行；同时观察 Sandbox 临时目录空间占用是否在请求执行后回落，而非持续增长。若仍持续失败，需检查 Sandbox 存储卷容量与清理逻辑是否已应用 PR #290 的修复。