n8n工作流调用Adobe PDF Services API时持续出现404 Not Found错误（疑似竞态条件问题）

我之前在处理Adobe PDF Services的异步转换流程时，也碰到过几乎一模一样的问题——上传文件返回200，但立刻调用转换就404，确实是Adobe的资产后台处理有延迟，不是单纯等几秒就能搞定的。结合你的情况，给你梳理一套可靠的解决方案：

第一步：先解决数据传递的核心问题 #

你提到线性流程里节点会丢失assetID、access_token这些关键数据，这是n8n节点输出的默认行为（新节点的输出会覆盖上一步的上下文），得用两种方式保证数据不丢：

方式1：利用节点自带选项保留上下文 #

• 对于「Create Asset」节点（POST /assets）：开启节点设置里的**「Include Input Data in Output」**，这样它的输出会包含上一步的所有数据，同时加上自身的响应（assetID、uploadUri等）。
• 对于「Upload File」节点（PUT到uploadUri）：把**「Keep Only Body」**设为false，这样它的输出会保留上一步（Create Asset）的assetID等数据，不会只返回上传的响应。

方式2：用Code节点手动合并数据（更灵活） #

如果自带选项不好用，就加一个Code节点放在Upload File之后，手动整合上下文和二进制数据：

// 把Create Asset的关键数据、Upload的响应、二进制文件都整合到输出里
return [{
  json: {
    ...$node["Create Asset"].json, // 继承Create Asset的assetID、access_token等
    uploadResponse: $json, // 保存Upload节点的响应
  },
  binary: $binary // 保留原始PDF的二进制数据
}];

第二步：解决竞态条件——轮询资产状态，确认可用后再启动转换 #

Adobe的资产上传完成后，后台需要几秒到十几秒的时间完成索引和状态同步，这时候直接调用转换会找不到assetID。不要用固定等待时间，必须轮询资产的状态直到它变为可用：

具体流程新增步骤： #

在「Upload File」之后，加入以下节点：

1. Loop On Item节点：设置循环条件为$json.status !== "available"（这里的status是Adobe资产接口返回的字段，你可以先调用一次GET /assets/{assetID}确认字段名）。
2. 循环内部依次放：
   • Wait节点：设置等待3秒（避免太频繁请求API）。
   • HTTP Request节点（Check Asset Status）：发送GET请求到/assets/{{$node["Create Asset"].json.assetID}}，带上有效的access_token，获取资产的当前状态。

当Loop节点退出时，说明资产已经处于available状态，这时候再调用「Start Conversion」节点，就不会出现404了。

针对你之前尝试方法的补充说明 #

• 固定等待时间没用：Adobe的资产处理时间不稳定，高峰期可能需要更久，轮询是最可靠的方式。
• 重试转换节点没用：你之前重试的是转换请求，但问题出在资产还没准备好，应该先确认资产可用，再发起转换请求。
• 并行流程绝对不能用：上传和转换必须严格串行，并行只会让竞态条件更严重。

额外排查点 #

• 确认「Start Conversion」请求里的assetID完全正确，没有拼写或大小写错误（Adobe的assetID是区分大小写的）。
• 检查你的access_token是否包含pdf_export和asset_management的权限（在Adobe Developer Console里可以查看）。
• 验证Upload的文件是否真的成功：登录Adobe Developer Console的「Assets」页面，看看有没有你上传的PDF文件，确认它的状态是「可用」。

最终可靠的工作流架构 #

触发节点 → Create Asset → Upload File → Loop On Item（轮询资产状态）→ Start Conversion → 轮询转换状态 → 下载结果

这样既解决了数据丢失的问题，又彻底规避了竞态条件，我用这套架构处理过上百次PDF转HTML的流程，再也没出现过404错误。

内容来源于stack exchange