Two failures stayed "unrepaired" after the fix had already shipped

说明与用途

自动化管道的账本在代码修复已合并后仍将两次失败标记为“未修复”，因为账本仅在后续运行明确引用失败运行的 repair_of 数组时才认为失败已修复。

问题

The automation pipeline’s ledger marked two failures as unrepaired even after the code fixes had merged, because the ledger only considered a failure repaired when a later run explicitly referenced the failed run in its repair_of array.

结果

The ledger correctly marked the failures as repaired only after a confirming run executed the affected paths, illustrating that code merges alone do not guarantee repair status without evidence of execution.

工作流

• 1. Identify unrepaired failures in the ledger.
• 2. Review failure records to confirm root causes were fixed in merged PRs.
• 3. Observe that the ledger’s repair rule requires a later run to list the failed run’s ID in its repair_of array.
• 4. Trigger a run that exercises the affected paths.
• 5. Verify the run succeeds and records the failed run IDs in its repair_of array.
• 6. Confirm the ledger updates the failures to repaired.

证据

The ledger still listed two failures from the two days before as unrepaired, even though the pull requests that fixed their root cause had already merged.

来源

scripts/autopilot-selfheal.mjs defines "repaired" as exactly one thing: the failing run's ID appears in another run's repair_of array.

来源

Only at that point did both rows close. Nothing about the underlying bug changed that day — the code had already been correct since the two fixes merged, two days earlier.

来源