---
title: "The automated repair command was one step from corrupting ten old tickets"
canonical: https://dxdev.com/blog/2026-08-18_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 and ready to run. 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 the check got flagged, and the fix that already existed for a failed check was to update the ticket to match the rule, in bulk, across every flagged item.

Before running it, I went through the 17 by hand instead of trusting the flag. Sixteen of them were false alarms. The check inferred a ticket's real state by reading a status log and guessing backward from it, instead of checking what had actually shipped, and it had no way to tell a ticket that had been formally retired years ago from one that had genuinely been delivered. Retired tickets and delivered tickets can both leave a status log that looks the same to a rule that isn't checking the one thing that would actually distinguish them.

## What the repair would have done

Ten of the sixteen false alarms were tickets from 2020 through 2022 that had already been retired, closed out and abandoned long before this check existed. Running the repair as designed would have stamped the current work cycle onto every one of them, rewriting a field on ten records nobody was working, based on a rule that never should have flagged them in the first place. That would not have been a cosmetic mistake. It would have been automated tooling confidently corrupting historical records because the detector feeding it couldn't tell old and settled from new and broken.

## What actually needed fixing

Only one of the seventeen was a real gap, one that genuinely disagreed with the rule and needed a hand correction, which I made directly rather than through the bulk repair. A second real gap turned up in the same pass, but it had already been flagged by the same watchdog weeks earlier and never acted on, so it wasn't part of this batch of seventeen at all. The watchdog itself got the real fix: instead of inferring status from a log, it now checks actual delivery history, and it now distinguishes a retired ticket from a delivered one before flagging anything. One condition the original rule enforced is still open and unresolved on purpose, left for a deliberate decision rather than folded into this fix.

## Why this generalizes past one ticket system

A detector and a bulk repair built for the same condition are usually built and reviewed together, as a matched pair, on the assumption that if the detector's logic looks correct, the repair is safe to run on whatever it flags. That assumption only holds if the detector's actual hit rate has been checked against ground truth, not just its logic reviewed on paper. A check that infers state indirectly, rather than reading the real source of truth, will eventually disagree with reality in a way that looks perfectly consistent from inside its own rule. The sixteen false alarms here didn't look like bugs in the check. They looked like sixteen tickets that needed fixing, right up until someone checked what had actually happened to each one.