Novu Provider发送为什么没有自动重试渠道/Provider层重试策略【免费下载链接】novuThe open-source communication infrastructure for agents and products项目地址: https://gitcode.com/GitHub_Trending/no/novu你通过 Novu 触发了一次通知Provider如 SendGrid、Twilio、FCM拒绝了请求你预期 Novu 会隔一段时间自动重发但 Activity Feed 里该步骤只是标记为 Failed 就结束了。这不是故障Novu 的渠道步骤发送channel step send只尝试一次Provider 拒绝即视为终态没有自动重试、没有退避、没有上限。本文基于 Novu 官方重试策略文档说明各层重试策略的差异并给出确认失败现象、接收失败信号和可用恢复手段的操作路径适用于排查“某次发送失败后为什么没有自动重发”的问题。先确认失败发生在哪一层Novu 在投递路径上有多处重试点策略各不相同。排查前先判断你观察到的失败属于哪一层因为“没有重试”只在渠道/Provider 层成立层是否自动重试尝试次数退避上限渠道步骤发送到 Provider否1 次无无Bridge endpoint 调用Novu Framework是3 次重试2^attempt × 500ms4 秒Novu 发出的出站 Webhook是8 次尝试固定时间表10 小时如果你用的是 Novu Framework代码定义的工作流Novu 调用你的 bridge endpoint 解析步骤内容时是会重试的对 HTTP408、429、500、503、504、521、522、524以及ECONNREFUSED、ECONNRESET、ETIMEDOUT、ENOTFOUND、EAI_AGAIN等瞬时网络错误最多重试 3 次延迟依次为 1 秒、2 秒、4 秒其他响应包括大部分4xx不重试每个请求有 5 秒超时。Novu 发往你端点的出站 webhook有独立的更长时间表立即、5 秒、5 分钟、30 分钟、2 小时、5 小时、10 小时、10 小时共 8 次尝试见 Webhook 文档的 Retry schedule 一节。只有“渠道步骤调用外部 Provider 发送”这一层没有重试这就是标题问题的答案所在。为什么渠道/Provider 层不做自动重试官方文档给出的原因是Provider 的拒绝通常是确定性的——收件人无效、模板被拒、账户被暂停、额度耗尽——重试会产生同样结果还会拖慢工作流其余步骤。关键行为细节Provider 调用抛异常或没有返回消息标识时Novu 会记录一条状态为Failed、内容为Unexpected provider error的 execution detail含 Provider 的原始响应发出messages.failedwebhook在 Activity Feed 中把步骤标记为失败然后继续执行工作流的下一步骤。Provider 拒绝按状态码一律视为终态429 Too Many Requests、503 Service Unavailable与400 Bad Request的处理方式相同。也就是说Provider 返回 429 不会被重试官方建议用 throttle 步骤限制工作流对同一订阅者的发送频率并自行检查 Provider 的发送限额。各渠道的差异Push会向订阅者所有已注册设备 token 发送部分 token 成功部分失败时步骤记为Warning并继续全部失败才标记 failedIn-appInbox不调用外部 Provider不存在 Provider 重试问题Email Webhook是唯一内部自带重试的 Provider会向配置的 webhook URL 最多重发 3 次、固定间隔 30 秒失败后才标记步骤失败。没有自动的 Provider 故障切换发送前 Novu 已为该渠道选定 integration该 Provider 失败后不会回退到同渠道的其他已配置 integration。Provider 一旦接受了消息步骤即标记成功之后的 bounce、运营商拒收等下游状态在支持时通过 Provider 投递回执反映到消息上不会触发重试。文档同时提醒正因为 Provider 发送不重试一次瞬时的 Provider 故障会导致受影响工作流运行的通知永久未送达需要通过messages.failedwebhook 来检测和响应。在 Activity Feed 中确认发送失败的具体现象确认“没有重试”是否符合预期按下面的路径检查参考 监控与调试工作流文档打开对应环境的 Activity Feed每个环境有各自独立的 Activity Feed进入Workflow Runs标签按时间范围、workflow identifier、channel 等条件过滤到目标运行。点开该 workflow run 的详情查看 execution details时间线按时间顺序展示每个步骤的处理结果。失败的渠道步骤会显示为 failed并带有Unexpected provider error的 execution detail 和 Provider 原始响应——这里能看到 Provider 具体返回了什么而不会看到第二次尝试的记录。判断步骤状态渠道步骤失败不会中断工作流后续步骤如失败邮件后的 SMS 步骤会正常排队执行只有 digest、delay、throttle 这类 action 步骤失败才会终止本次运行并取消该订阅者后续所有步骤。如果你在 execution details 中只看到这一次失败尝试、且状态与上表一致说明行为符合 Novu 的设计而不是发送链路异常。订阅 messages.failed 获取程序化失败信号由于失败不会自动重发文档建议的响应方式是订阅messages.failedwebhook该事件在 Novu 尝试把消息发给投递 Provider 且失败时触发见 webhooks 文档。收到该事件后由你的系统决定如何处理这次特定失败补偿、告警或人工介入。事件的字段说明可参考 事件类型文档。配置方式与验证方式与其他 webhook 一致在 webhook 管理的 Testing 标签发送测试事件后可以查看消息 payload、所有尝试记录以及每次尝试的成功/失败状态如果端点未就绪也可以先用 webhook 测试服务生成一个临时 URL 验证连通性。失败后的恢复手段与边界Novu没有可供检查或重新驱动的 dead-letter queue失败的步骤连同 Provider 错误一起记录在 Activity Feed 中官方明确把 Activity Feed 和messages.failedwebhook 作为失败投递的记录。因此对渠道/Provider 层的失败恢复动作只能由你在收到messages.failed后自行发起例如重新触发工作流。以下恢复能力只对出站 webhook 消息有效不要误用于 Provider 发送失败的场景在应用 portal 中可以对单条消息手动重试在消息的任一尝试旁点开菜单选择 resend也可以从给定时间起自动恢复Recover所有失败消息若某端点连续 5 天全部尝试失败会被禁用需在 webhook 面板中选择 Enable Endpoint 重新启用端点 15 秒内未响应 2xx 即视为一次失败。最后的限制清单均无配置项可调各层的重试次数与退避是固定的不能按 workflow、步骤或 integration 配置渠道步骤的重试次数Provider 失败不会触发同渠道其他 integration 的自动 failoverProvider 接受即成功下游投递失败bounce 等不触发重试渠道步骤失败不影响后续渠道步骤执行action 步骤失败则终止本次运行。如果你的排查结论是“失败的是 bridge endpoint 调用或出站 webhook 而非 Provider 发送”则无需额外操作——这两层各自按上文表格中的策略自动重试webhook 消息还可通过 UI 手动重放。【免费下载链接】novuThe open-source communication infrastructure for agents and products项目地址: https://gitcode.com/GitHub_Trending/no/novu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
