Dify 插件存储超限错误分析报告

错误来源

这个错误的根本原因并不来自 Dify Python API 的代码库，而是源于一个独立的 Go 服务 —— dify-plugin-daemon。该服务专门负责管理插件的运行环境。简单来说，整个错误链路如下：

1. 插件在工作流中调用 session.storage.set() 保存数据时触发存储请求。
2. Plugin daemon 接收到请求后，会立即检查存储大小限制。
3. 一旦发现已分配或累计使用的存储空间超出上限，系统便会返回错误：allocated size is greater than max storage size。
4. 上层服务将此错误包装为用户看到的提示信息：save data failed: allocated size is greater than max storage size。

两层存储限制机制

这里需要重点理解的是，Plugin daemon 实际上设有两道“紧箍咒”，共同约束存储使用：

Plugin daemon 会同时校验这两个限制，最终以更严格的那一个为准——即取较小的值作为实际生效上限。数据库中的 tenant_storage 表会依据 tenant_id 和 plugin_id 的组合，精确记录每个插件当前的累计存储用量。

解决方案

以下提供两种维度的修改方式，您可根据实际需求组合选用：

方案一：增大插件 manifest 中的 storage.size（推荐）

定位到出错插件的 manifest.yaml 文件，调大 storage.size 参数值。例如，将默认的 1MB 修改为 10MB：

resource:
  permission:
    storage:
      enabled: true
      size: 10485760  # 改为 10MB

size 的取值范围为 1024 (1KB) 到 1073741824 (1GB)，可覆盖绝大多数应用场景。

方案二：调高全局 PERSISTENCE_STORAGE_MAX_SIZE

在 docker/envs/core-services/plugin-daemon.env 文件中添加或修改以下配置：

PERSISTENCE_STORAGE_MAX_SIZE=524288000  # 500MB

也可通过 .env 文件设置，效果完全相同。

方案三：在 Dify 管理后台清理插件已占用的存储

如果插件已积累大量历史数据，也可以直接从数据库层面进行清理。使用以下两条 SQL 语句操作：

-- 查看某个租户下各插件的存储用量
SELECT tenant_id, plugin_id, size FROM tenant_storage ORDER BY size DESC;

-- 清理特定插件的存储记录（让插件重新开始计数）
DELETE FROM tenant_storage WHERE tenant_id = 'your_tenant_id' AND plugin_id = 'your_plugin_id';

推荐排查步骤

若遇到此问题，可按以下顺序逐一排查：

1. 锁定报错的具体插件 — 查看 plugin_daemon 容器的日志：

   docker logs dify-plugin-daemon-1 --tail 100

2. 检查该插件的 manifest.yaml，确认当前 storage.size 的具体数值。

3. 查询数据库 tenant_storage 表，了解该插件当前的累计存储用量。

4. 根据实际需要存储的数据量，从方案一或方案二中选取合适的调整方式。