重试策略
如何设计 Twitter API 任务的 retry 和 backoff，避免把真正的流程问题藏起来
retry 只有在范围够窄、足够可见、而且只对应明确的临时失败时才有价值。太宽的重试策略，会让 Twitter / X 任务表面健康，实际上把 query、schedule 或 workflow 边界问题都藏起来。
1. 先区分临时失败和工作流失败
稳的 retry 策略通常从一个简单问题开始：这是临时条件，还是说明整条 workflow 本身需要复核？
比如空结果，很多时候更应该被诊断，而不是自动重试。
- 把 retryable failure 显式分类。
- 把 suspicious-empty 或 malformed run 送去复核，而不是盲重试。
- 给失败类型保留一套共享定义。
2. backoff 最好窄而且可预测
当等待策略散落在不同代码路径里时，团队很容易失去对任务时长的判断。
更稳的方式通常是针对不同失败类别，只保留少数可解释的等待规则。
- 每类失败只保留一套 backoff 规则。
- 保存 retry 次数和下一次尝试时间。
- 避免无限或含糊不清的重试循环。
3. 保留第一次失败的上下文
第一条错误通常包含最好的排障信号。如果后面的 retry 把这层上下文覆盖掉，任务就会很难再被信任。
好的 run record 会同时保留 first failure 和 final outcome。
- 把 first-failure context 和最终状态分开保存。
- 保留原始 query 或 endpoint stage。
- 记录第几次 retry 才成功或最终失败。
4. 把重复 retry 当作工作流反馈
如果同一类任务长期需要重试，问题很可能不是运气差，而是 schedule、请求压力或 workflow scope 有问题。
稳的团队会把 retry history 当成维护输入，而不仅仅是补救手段。
- 按 job type 审核重复 retry。
- 把 retry-heavy 任务列入维护清单。
- 检查 retry 是否正在掩盖 schedule 或 rate 问题。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
空结果 run 应该自动 retry 吗？
通常不该。空结果更常需要回看 query 意图、filter 或 checkpoint，而不是盲重试。
backoff 策略最少该记录什么？
至少要有失败类型、retry 次数、下一次尝试时间，以及触发它的 first failure 上下文。
团队最常见的 retry 错误是什么？
用太宽的 retry 把工作流设计问题藏起来，结果让后面的 debug 更难。
这一环通常会一起看的页面
如果你想看包含 retry 在内的整体失败策略，可以继续看这页。
如果重试大多是因为限流压力，可以继续看这页。
如果重试背后更像 schedule 设计问题，可以继续看这页。
如果你想回到文档里的错误页对照，可以继续看这里。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。