👁 17 次阅读

Outlook 节点创建草稿添加附件为何报 UnableToDeserializePostBody？

来源链接：https://github.com/n8n-io/n8n/issues/23132

现象描述

n8n 的 Microsoft Outlook 节点在执行「Create a draft」操作并附带附件时，会收到 Microsoft Graph 返回的 400 错误。issue 报告者给出的原始报错如下：

{
  "errorMessage": "were unable to deserialize ",
  "errorDetails": {
    "rawErrorMessage": [
      "400 - {\"error\":{\"code\":\"UnableToDeserializePostBody\",\"message\":\"were unable to deserialize \"}}"
    ],
    "httpCode": "400"
  }
}

n8nDetails 中的元数据标明了环境与节点位置：nodeType 为 n8n-nodes-base.microsoftOutlook，nodeVersion 为 2，resource 为 draft，operation 为 create，n8nVersion 为 2.0.1 (Cloud)，binaryDataMode 为 filesystem。堆栈落点在 n8n-nodes-base/nodes/Microsoft/Outlook/v2/actions/draft/create.operation.ts:252:23，并经 Microsoft/Outlook/v2/transport/index.ts:52:10 的 microsoftApiRequest 抛出。 issue 正文引用了社区论坛的一篇帖子作为背景，标题为「Error on Outlook node Create Draft when adding and attachment」。从现象看，请求体在到达 Microsoft 一侧时无法被反序列化，而不是认证失败或权限不足（后者通常返回 401/403）。同一节点在不带附件、或执行其他 draft 操作时表现是否正常，报告中没有逐一列出。 讨论中另一位用户 TheNexter 在 2025-12-17 反馈了完全相同的报错：Error 400 { "error": { "code": "UnableToDeserializePostBody", "message": "were unable to deserialize " } }，并补充「Was working perfectly in 1.0 but i upgrade to 2.0 this morning and this error appear」，把怀疑指向 2.0 版本。该用户的判断属于个人推测，官方在此后的回复中并未确认这一点。

背景原因

从讨论的实际推进看，问题被定位到「附件二进制数据的传递方式」这一层。2026-01-12，用户 joshrenshaw12 给出了一段被后续多次引用的观察：该问题出现在使用 S3 作为二进制文件存储的自托管实例上；在他的测试中，当二进制数据存放在 S3 时，传给 Outlook Draft 节点的是 S3 的 URL，而不是节点所期望的实际二进制数据，这被其认定为报错原因。这是社区侧最具体的一条归因，issue 中维护者 MookieLian 回复「Thanks for the additional information, I’ll notify our team to investigate further」，即转交团队进一步调查，并未对该归因做出确认。 也就是说，issue 中可核实的因果链条只有「S3 存储模式 + 添加附件 → 传入的是 URL 而非二进制内容 → Graph 无法反序列化请求体」这一条社区结论，标注为据 issue 讨论。n8n 内部在二进制存储抽象层如何把 S3 对象转换为请求体，issue 中没有展开，该功能的具体实现尚未公开。 另一位用户 TheNexter 曾把 create.operation.ts 与 message 相关文件交给 Gemini 对比，希望定位差异，并明确表示自己「I’m not a javascript developer, i don’t know if this correct」。该对比结论在讨论中没有被验证，也没有维护者采纳，因此不能作为原因依据。 值得注意的是，问题并不严格绑定 S3。2026-01-21，djboris9 反馈在自托管、无 S3 的 2.2.6 版本上遇到同样问题，升级到 2.5.0 后消失，并说明没有进一步排查，不清楚具体在哪个版本修复。这与 S3 归因构成分歧：同一报错在不同环境、不同版本上都出现过。

排查或量化方法

issue 讨论中实际出现过的定位手段集中在环境变量与存储模式两条线上，没有出现日志采集或抓包相关的具体步骤。 可复现的环境维度如下：

• 部署形态：Cloud 与自托管均被报告。原始报告为 2.0.1 (Cloud)，后续跟帖多为自托管。
• 二进制存储：是否使用 S3。joshrenshaw12 明确指向 S3；djboris9 明确说明「No S3」也能复现。
• 版本：从 2.0.1 到 2.6.4 都有相关反馈，跨越多个小版本。
• 附件类型：battosai30 在 2.6.4 上反馈按文件类型表现不同，PDF 成功、XLSX 失败，但随后自行更正「Finally it was not a reliable information」，说明该分类不可作为结论。

版本与环境的对应关系可以整理为下表，用于判断自身实例是否落在已报告的区间内：

报告者	版本	部署/存储	关键观察
原始报告	2.0.1 (Cloud)	Cloud，binaryDataMode 为 filesystem	添加附件即报 400
TheNexter	2.0	自托管（1.0 正常）	升级到 2.0 后出现
joshrenshaw12	未写明	自托管 + S3	传入的是 S3 URL 而非二进制
20Bosko07	未写明	自托管	同样问题
djboris9	2.2.6 → 2.5.0	自托管，无 S3	2.2.6 复现，2.5.0 消失
battosai30	2.6.4	自托管，无 S3	设置 _N8N_DEFAULT_BINARY_DATA_MODE=default 后解决
TheNexter（后续）	未写明	未写明	数月后仍存在，用 HTTP 节点绕过
量化层面，issue 中没有任何性能指标或失败率统计，可用信息只有上表中的定性反馈。
完整解决方案
需要先明确结论：该 issue 状态为 closed，关闭原因为 completed，2026-10-11 关闭。但通读剔除机器人留言后的实质讨论，维护者 MookieLian 的公开回复只有两类——建议转到社区论坛提问，以及「I’ll notify our team to investigate further」。讨论中不存在维护者确认复现并给出修复版本号的回复，也没有出现 PR 编号或合并记录。因此准确的表述是：issue 已关闭归档，但官方未在讨论中提交修复，关闭原因与维护者判定无关。后续是否由其他改动顺带解决，issue 中没有可核实的信息。
社区侧可用的处理路径，均来自 issue 跟帖，属于社区结论而非官方确认：
1. 提升 n8n 版本。djboris9 在 2.2.6 复现、在 2.5.0 不再出现，并建议「you might have luck just by upgrading n8n」，同时声明未定位到具体修复版本。反例是 TheNexter 在 2026-04-16 仍反馈问题存在，battosai30 在 2.6.4 仍遇到，说明升级不是稳定解法。
2. 调整默认二进制数据模式。battosai30 给出的 workaround 是设置环境变量：
_N8N_DEFAULT_BINARY_DATA_MODE=default
其原话为「Setting _N8N_DEFAULT_BINARY_DATA_MODE=default solved the issue」，并附上了社区论坛帖子链接（https://community.n8n.io/t/help-the-node-add-attachement-to-a-draft-does-not-work/251625/9）。该模式取值与 filesystem、S3 之间的关系，issue 中没有说明，若实例依赖 S3 存储大附件，切换前需要自行评估存储影响。这一配置是否有副作用、在哪些版本上生效，讨论中均未验证。
3. 改用 HTTP Request 节点直接调用接口。TheNexter 表示「i still use http node to bypass the problem」，即在 Outlook 节点之外自行构造请求。该路径没有在 issue 中给出具体请求体写法，需要按 Microsoft Graph 的 draft 接口自行实现，维护成本由使用者承担。
4. 等待并跟踪。20Bosko07 在 2026-02-08 追问「Something new?????」，未得到实质答复，说明在关闭前该问题已长期无进展。
上述方案之间不存在官方推荐的优先顺序，取舍依据自身的存储配置和对附件功能的依赖程度。
参数或对比表格
下表对比 issue 中出现过的三种处理路径，仅归纳讨论中的原话事实，不评价其在未测试环境下的有效性：
路径	依据来源	适用前提	已知局限
升级 n8n 版本	djboris9（2.2.6 → 2.5.0）	当前版本落在受影响区间	具体修复版本未知；TheNexter、battosai30 在新版本仍复现
设置 _N8N_DEFAULT_BINARY_DATA_MODE=default	battosai30	自托管，可修改环境变量	仅单条反馈；与 S3 存储模式的兼容性未说明
用 HTTP Request 节点替代	TheNexter	能自行构造 Graph 请求	需自行维护请求体；issue 中未给出实现

与错误直接相关的字段可以归为三类：errorMessage 为 were unable to deserialize （注意结尾带空格，为原文），rawErrorMessage 中含 UnableToDeserializePostBody，httpCode 为 400。这三个字段在 Cloud 与自托管、S3 与非 S3 的反馈中保持一致，可作为检索该问题的关键词。

常见错误排查

以下条目均基于 issue 中已经出现过的反馈整理，官方侧没有在讨论中给出排查清单。

• 先确认二进制存储是否为 S3。joshrenshaw12 的测试表明 S3 模式下传入的是 URL 而非二进制内容；若实例启用了 S3，优先在该维度上复现。该结论为社区观察。
• 不要仅凭版本号判断是否已修复。djboris9 在 2.5.0 恢复，但 battosai30 在 2.6.4 仍失败，TheNexter 在 2026-04-16 仍存在，版本与结果之间没有稳定对应关系。
• 不要以文件类型作为分类依据。battosai30 先报告 PDF 成功、XLSX 失败，随后明确更正为不可靠信息。
• 确认报错文本是否完全一致。本 issue 的统一特征是 UnableToDeserializePostBody 加 HTTP 400；若报错为认证或权限类，属于另一类问题，不在本 issue 范围内。
• 若修改了 _N8N_DEFAULT_BINARY_DATA_MODE，需确认该实例原本的存储模式，issue 中未覆盖切换后的存储行为差异，也没有其他人按同一配置反馈结果，因此不存在交叉验证。

实践建议

对依赖 Outlook 节点发送带附件草稿的团队，短期内把附件路径视为高风险点：在流水线中对该节点加失败告警，避免草稿创建失败被静默吞掉。若实例使用 S3 存储，按 joshrenshaw12 的观察，问题概率更高，建议在测试环境固定一个带附件的 draft 用例做回归。 对版本升级保持谨慎乐观。djboris9 的经验说明升级可能有效，但缺乏修复版本号，不能把某个具体版本当作安全线；升级后需用同一用例验证，而不是仅看版本号。 对自托管且可改环境变量的实例，可评估 _N8N_DEFAULT_BINARY_DATA_MODE=default。该配置只有 battosai30 一条成功反馈，且未说明与其他二进制存储需求的冲突，建议先在非生产实例验证。 由于 issue 已在无官方修复确认的情况下关闭，后续若再遇到同一报错，通过新 issue 或社区论坛反馈比在该条目下追问更有效——20Bosko07 在 2026-01-10 的「Something new?? Really need it!」与 2026-02-08 的「Something new?????」，以及 TheNexter 的「Up, after all those month the problem still here」，都没有得到维护者的实质答复。

FAQ

Q1：这个报错是认证问题吗？ 不是。Graph 返回的是 HTTP 400 与 UnableToDeserializePostBody，表示请求体无法反序列化；认证类问题通常表现为 401/403。issue 中的元数据也未指向凭据。 Q2：升级 n8n 能解决吗？ 据 issue 讨论，djboris9 在 2.5.0 上不再复现，但未定位具体修复版本；TheNexter 与 battosai30 在更高版本上仍有反馈。因此升级可能有效但不能视为确定解法。 Q3：只有使用 S3 才会触发吗？ 不是。joshrenshaw12 将原因指向 S3 存储下传入 URL 而非二进制内容，但 djboris9（自托管、无 S3）与 battosai30（自托管、无 S3）均在无 S3 环境下复现，说明还存在其他触发路径，issue 中未进一步定位。 Q4：_N8N_DEFAULT_BINARY_DATA_MODE=default 是官方方案吗？ 不是。该配置来自 battosai30 的跟帖，属社区 workaround，附带了社区论坛链接。issue 中没有维护者确认，也没有其他人交叉验证，使用前需自行测试。 Q5：issue 已关闭，是否意味着已修复？ 不能这样理解。关闭原因为 completed，但讨论中维护者只做了转交调查与论坛引导，没有确认复现、没有给出修复版本号、没有 PR 或合并记录。准确说法是 issue 已关闭归档，官方未在讨论中提交修复，社区侧仍有升级、改环境变量、改用 HTTP 节点等缓解手段，且各自存在局限。