---
title: "One Command Could Have Rewritten Ten Retired 2020 Tickets"
canonical: https://dxdev.com/blog/the-repair-command-almost-ran/
datePublished: 2026-08-18
---
The daily alert said 17 tickets were inconsistent, and the repair for that exact condition was already written. One command, and all 17 would be brought into line.

## What "inconsistent" actually meant

The check compared each open ticket against a simple rule: certain fields should agree with certain other fields by the time work is considered done. Any ticket that failed got flagged. The fix that already existed for a failed check was to update the ticket to match the rule, in bulk, across every flagged item.

We didn't run it. We went through the 17 by hand first, and sixteen were false alarms. The check inferred a ticket's real state by reading its status log and guessing backward, instead of looking at what had actually shipped. It had no way to tell a ticket that was formally retired years ago from one that was delivered. Both can leave a status log that looks identical to a rule that isn't checking the one thing that would separate them.

## What the repair would have done

Ten of those sixteen were tickets from 2020 through 2022 that had been retired, closed out and abandoned long before this check existed. Run as designed, the repair would have stamped the current work cycle onto every one of them. That is a field rewritten on ten records nobody was working, driven by a rule that should never have flagged them. The detector couldn't tell old and settled from new and broken, and the repair would have trusted it completely.

## What actually needed fixing

Only one of the seventeen was a real gap. It disagreed with the rule, and we corrected it by hand rather than through the bulk repair. A second real gap turned up in the same pass, but the same watchdog had flagged it weeks earlier and nobody acted on it, so it was never part of the 17.

The fix went into the watchdog. It no longer infers status from a log. It checks actual delivery history, and it separates a retired ticket from a delivered one before it flags anything. One condition the original rule enforced is still open on purpose.

## Why the pair looked safe

A detector and its bulk repair are usually built and reviewed together, on the assumption that if the detector's logic reads correctly, the repair is safe on whatever it flags. That only holds if the detector's hit rate has been checked against ground truth. Reviewing the logic on paper doesn't do it. A check that infers state indirectly will eventually disagree with reality in a way that looks perfectly consistent from inside its own rule. The sixteen false alarms didn't look like bugs in the check. They looked like sixteen tickets that needed fixing, until we checked what had happened to each one.

So before an automated bulk repair runs, pull a sample of what the detector flagged and compare it with what actually happened. If you own an alert-and-fix pair, find out whether anyone has verified the detector's hit rate, or only reviewed its logic.