[r2cn] Orion 构建链路并发幂等与 Buck2 稳定性治理

[benjamin-747]

[任务] Orion 构建链路并发幂等与 Buck2 稳定性治理

[任务分值] 30 分

[背景描述]

Orion 是 Mega 构建链路中的执行与调度核心：当前用户与系统会通过多条路径触发 Orion：
  - 开发者 git push 后触发 CI；
  - Web IDE 保存代码后触发构建；
  - 页面手动触发构建；
  - 失败后重试构建。
  这些动作最终会汇聚为对 Orion 的构建请求（如 POST /task / POST /retry-build）。在真实环境中，上游事件投递通常具备重试语义，再叠加用户手动重试、网络抖动、worker 并发消费，容易出现“短时间重复触发同一构建”的情况。
 
  目前 Orion 构建链路在并发与稳定性方面仍需完善，主要表现为：
  - 同一 build_id 在短时间内被重复触发时，系统可能出现重复执行、状态不一致，或用户侧感知“请求丢失/结果冲突”。
  - 在已有构建处于运行中时再次触发构建，当前流程可能直接返回冲突错误；同时新请求未被可靠入队或持久化，造成“新触发未生效”的体验。
  - 上述现象说明运行中任务与新触发之间缺少统一的冲突处理与排队机制，这是并发一致性治理的核心问题。
  - 在 Buck2 + FUSE 场景下，仍存在 daemon 连接失败、锁/I/O 异常、stale handle 等底层稳定性风险。
  - 目前链路缺少统一的端到端幂等与恢复机制，故障定位高度依赖日志串联，排查成本高、恢复效率低。

[需求描述]

  - 完成服务端构建任务幂等治理，避免同一任务重复执行
  - 完成 Worker 侧并发控制增强，降低重复消费与并发冲突
  - 完成 Buck2/FUSE 相关稳定性优化与失败重试机制
  - 补充必要的监控指标、回归测试与调试文档

  - 完成功能的同时保持代码简洁
  - 同 build_id 并发触发 N 次，仅 1 次实际构建执行，其余请求返回同一任务状态
  - worker 重启/断连场景下无任务丢失、无重复执行
  - Buck daemon 连接类错误率较基线显著下降，且具备自动恢复能力
  - 新增测试与现有 CI 全部通过

[代码标准]

1. 所有 PR 提交必须签署 Signed-off-by 和 使用 GPG 签名，即提交代码时（使用 git commit 命令时）至少使用 -s -S 两个参数，参考 Contributing Guide；
2. 所有 PR 提交必须通过 GitHub Actions 自动化测试，提交 PR 后请关注 GitHub Actions 结果；
3. 代码注释均需要使用英文;

[PR 提交地址] 提交到 mega 仓库的 main 分支 `` 目录；

[开发指导]

1. 认领任务参考 r2cn 开源实习计划 - 任务认领与确认;

[导师及邮箱] 请申请此题目的同学使用邮件联系导师，或加入到 R2CN Discord 后在 #p-meta 频道和导师交流。

1. Quanyi Ma genedna@gmail.com
2. Tianxing Ye yetianxing2014@gmail.com

[备注]

1. 认领实习任务的同学，必须完成测试任务和注册流程，请参考： r2cn 开源实习计划 - 测试任务 和 r2cn 开源实习计划 - 学生注册与审核

[r2cn-bot]

任务创建成功。

[jerry609]

/request-assign

[r2cn-bot]

认领成功：等待导师审核，请及时联系导师进行审核。

[benjamin-747]

/intern-approve

[r2cn-bot]

认领审核成功：已将该任务分配给学生。