buffalo调度系统不支持worker内建重试策略，重试必须在task定义中显式声明maxretrytimes、retryintervalseconds和retryonfailure字段，且仅对非零退出码的失败生效。
Buffalo调度系统不支持Worker内建重试策略
Buffalo 是京东自研的分布式 DAG 调度系统，它的重试控制粒度在 Task（任务）层级，而非 Worker 进程或执行单元内部。Worker 只负责拉取已调度的 TaskInstance 并执行其 Action，本身不提供 retry 配置入口——试图在 Worker 启动参数、环境变量或配置文件里找 retry_count 或 backoff_policy 都会失败。
重试必须在 Task 定义中显式声明
Buffalo 的重试逻辑由任务定义时的元数据驱动，实际生效的是 Task 对象上的重试字段。常见错误是把重试逻辑写进 Action 脚本里（比如 shell 里套 for 循环），这会导致：调度层无法感知失败、监控指标失真、依赖阻塞、实例状态混乱。
-
maxRetryTimes：整型，指定该 Task 最大重试次数（含首次执行），设为0表示不重试 -
retryIntervalSeconds：重试间隔秒数，支持固定值，不支持指数退避（Buffalo 当前版本无 jitter 或 exponential backoff 配置项） -
retryOnFailure：布尔值，仅对非EXIT_CODE=0的失败生效；若 Action 主动 exit 0 但业务失败，不会触发重试 - 重试仅作用于当前 TaskInstance，上游依赖不会被重新触发，也不会影响其他周期的实例
遇到“重试没生效”先查这三处
重试失效的常见原因和排查路径：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- Task 定义未提交或版本未发布：修改重试参数后必须重新发布 Task 版本，旧实例仍按原配置运行
- Action 脚本 exit code 始终为 0：即使内部报错也用
exit 0掩盖，导致 Buffalo 认为执行成功，跳过重试判断 - 失败类型被标记为“不可重试”：例如资源超限（
OOMKilled）、Worker 失联、超时 Kill 等系统级终止，这类失败不进入重试流程，而是直接标记为FAILED
需要指数退避或条件重试？得绕开原生机制
Buffalo 当前不支持基于错误码、异常文本或返回内容做条件重试（比如只对 "Connection refused" 重试，对 "Invalid input" 不重试）。如果业务强依赖这类逻辑，可行方案只有：
- 在 Action 脚本内自行实现重试（用
while+sleep+ 错误匹配），但需确保最终 exit code 正确反映整体成败 - 将重试逻辑下沉到被调用的服务端（如 HTTP 接口自身支持重试），让 Buffalo 的单次调用变“幂等且高成功率”
- 用 Control Node 搭建一层轻量编排：把一个逻辑任务拆成多个串行 Task，用失败分支跳转模拟条件重试
真正容易被忽略的是：Buffalo 的重试计数器在 TaskInstance 生命周期内累计，但每次重试都会生成新的日志流和临时目录——如果你在 Action 里依赖 /tmp 下的残留文件，重试时可能读到脏数据或路径冲突。
