【要約】自分が作った worktree 並列機構に裏切られ、自分が設計した fallback で完走した話 ── + 基盤整備トリロジー [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がマルチエージェント・フレームワーク C3 の基盤整備を進める際、目玉機能である git worktree を用いた並列実行機構が予期せぬ不具合を引き起こした。前回検証で動作を確定させたはずの機構が、特定の条件下で連鎖的な異常を発生させた。
- ・worktree 内への cwd 漏洩により、親プロセスの相対パス操作が誤ったリポジトリを指した。
- ・worktree とメインリポジトリの両方に成果物が書き込まれる二重書き込みが発生した。
- ・Windows 環境において、ファイルロックにより worktree の自動削除が失敗した。
// Approach
開発者は、目玉機能の故障に備えて設計していた「非 worktree フォールバック」と「git 操作の原則」を適用して問題を回避した。派手な並列化を諦め、確実な経路を選択することで開発を継続した。
- ・
git -C <path>を用い、作業ディレクトリに関わらずメインリポジトリを確実に操作した。 - ・ソースを書き換えないタスクは、worktree 隔離を解除した非並列モードへ切り替えた。
- ・
git worktree pruneを活用し、物理削除できないディレクトリを git 管理外として処理した。 - ・最終的なコミット履歴は squash し、クリーンな状態のみを push した。
// Result
開発者は、並列機構の不具合を抱えながらも、全ての基盤整備タスクを完走させた。これにより、フレームワークの信頼性を高める重要なアップデートが実現した。
- ・v2.27.0 および v2.28.0 のリリースを予定通り完了した。
- ・
c3 recallの増分 rebuild 実装により、再埋め込みコストを大幅に削減した。 - ・CI 導入により、OS 依存のバグを初日に検出する成果を得た。
- ・「auto-cleanup は常には成立しない」という反証に基づき、知見を更新した。
Senior Engineer Insight
> 本件は、高度な並列化よりも「異常系へのフォールバック設計」がシステムの生存率を高めることを示している。特に Windows 環境のような、ファイルロック等の OS 依存の挙動が絡む場合、目玉機能の失敗は避けられない。その際、
git -C によるパス固定や、非並列モードへの切り替えといった「地味だが確実な代替経路」を平時から設計しておく重要性は極めて高い。また、実証済みの結論であっても反証が出れば即座に更新する姿勢は、信頼性の高いシステム運用において不可欠な規律である。