快速结论:该报错通常发生在 n8n 通过 MCP Client(HTTP Streamable)调用 Dify Cloud MCP Server 并执行任意工具时,属于 Dify Cloud 侧 MCP 控制器的数据库会话管理缺陷,用户侧无法直接修复。优先确认问题是否只在 Dify Cloud 出现、而自建/VPS 托管 MCP Server 是否正常。
适用环境:Dify 1.16.1(Cloud);n8n 自托管;MCP Transport 为 HTTP Streamable。Issue 未提供操作系统、Python、CUDA、显卡等环境信息。
最快修复方案:暂无确认的一步修复方案。由于是 Dify Cloud 服务端回归,Cloud 用户只能等待官方修复;自托管用户可优先尝试按 Issue 讨论中给出的方向修改 api/controllers/mcp/mcp.py 的会话管理方式(详见“解决步骤”)。
注意事项:Dify Cloud 用户无法自行应用代码级修复,需等待 Dify Cloud 基础设施侧更新;自托管改写会话逻辑属于推测性 workaround,尚未在本 Issue 中由维护者确认,修改前请备份并充分测试。
问题场景
用户在 Dify Cloud(1.16.1)中创建 MCP Server,然后在自托管 n8n 中配置 MCP Client 节点,使用 Dify MCP 端点并通过 HTTP Streamable 传输调用该 Server 暴露的任意工具。执行工作流时,工具调用立即失败并返回 MCP 错误。
用户已做的额外验证:测试了多个 Dify Cloud MCP Server、来自不同 Dify Cloud 账号的 MCP Server、以及此前可正常工作的旧 MCP Server;同时用简单工作流排除复杂度因素;同一个 n8n MCP Client 连接 VPS 自托管的 MCP Server 可以正常通信。因此问题指向 Dify Cloud MCP 服务本身,而非 n8n 客户端。用户还指出该问题从 2026-08-04 开始出现,此前相同的 Dify Cloud MCP Server 无需改动即可正常工作。
报错原文
MCP error -32603: Internal server error:
Can't operate on closed transaction inside context manager.
Please complete the context manager before emitting further commands.
原因分析
根据 Issue 讨论中 Dosu 的答复,这是一个已被多人复现的确认缺陷,根因是 MCP 控制器代码中的 SQLAlchemy 会话管理问题:api/controllers/mcp/mcp.py 将请求包在 sessionmaker().begin() 上下文中,该上下文在退出时会自动提交。当下游调用 AppGenerateService.generate() 时,生成代码路径内部执行了一次 session.commit(),导致事务被提前关闭;此后任何 ORM 操作(例如设置 conversation.override_model_configs)都会失败,因为事务已关闭,从而抛出上述 -32603 错误。
讨论指出该问题由 PR #34281 引入,该 PR 将 MCP 控制器迁移到 sessionmaker().begin(),但未考虑 app generation 流程中的内部 commit;这与 #39191(dataset 路径,已在 1.16.1 修复)属于同类问题,但 MCP 路径当时尚未处理。另有 #37403 作为更广泛会话重构的 umbrella issue,#39787 为自托管环境下的同一缺陷报告。
环境排查
- 确认 Dify 部署形态与版本:本 Issue 为 Dify 1.16.1 Cloud;同时确认是否也存在自托管实例(对应 #39787)。
- 确认 n8n 部署方式(本 Issue 为自托管)及 MCP Client 使用的传输协议(HTTP Streamable)。
- 确认 MCP Server 创建位置:Dify Cloud 还是 Dify 自托管。
- 确认故障是否跨账号、跨 MCP Server 复现,以排除单个工具或工作流配置问题。
- 用同一个 n8n MCP Client 连接非 Dify 的 MCP Server(如 VPS 自托管)验证客户端本身是否正常。
- 确认问题起始时间点是否与 Dify 侧版本/变更相关(Issue 中记录为 2026-08-04 开始)。
解决步骤
- Dify Cloud 用户:暂无用户可执行的服务端修复步骤,只能等待 Dify Cloud 基础设施侧合入修复。可关注 #40007、#39787、#37403 的进展。
- 自托管用户(可优先尝试,尚未由维护者在本 Issue 确认):将
api/controllers/mcp/mcp.py中的sessionmaker(...).begin()上下文替换为普通会话Session(db.engine, expire_on_commit=False),并显式管理 commit,参考 #36392 等 PR 的修复模式。 - 修改前先备份对应文件与数据库,并在测试环境验证工具调用路径(包含会触发内部 commit 的 app generation 流程)后再上生产。
- 若自托管环境已有可用旧版本,可评估临时回退到未引入该会话变更的版本;但 Issue 未给出明确可用版本号,需自行验证。
验证方法
在 n8n 中用同一个 MCP Client 节点重新执行此前失败的工作流,调用 Dify MCP Server 暴露的工具:若不再返回 MCP error -32603: Internal server error,且工具正常执行并返回预期结果,即视为问题解决。建议同时用多个 MCP Server 和不同账号复测,确认为服务端整体修复而非个例。
参考来源
相关:langgenius/dify #39787、langgenius/dify #38998、langgenius/dify #37403、langgenius/dify PR #34281、langgenius/dify PR #36392
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


