the state that outlived the thing it described
The platform had already ended three items. The local state still believed all three were open. Every pass therefore re-issued a close request for them, the platform refused each one because the item no longer existed, and the pipeline counted the attempt as work: thousands of refusals, no effect, and a log that looked busy from a distance.
A defect that accomplishes nothing is easy to postpone. The one beside it was not. In the same path, when a reversal's closing step failed, the failure was swallowed and the opposite entry proceeded anyway, which can leave two open items where the design intends one. That is the failure nobody notices until the day it matters, and it was sitting next to the harmless one.
The fix made the platform's live record the starting truth of every pass. Items the platform no longer holds leave the state and are recorded as closed by reconciliation, with no request sent, because there is nothing left to close. Items that survive get their identifier refreshed, since a partial close re-identifies them. A failed close now aborts the step that depended on it instead of being written down and forgotten.
The reconciliation carries its own tests, including one against the tempting shortcut of adopting whatever the platform holds, even items the system never opened. What it proves is that they look specifically for the failures that raise no error, and that they are as suspicious of a busy log as of an empty one.
drawn from: a live pass that had been re-issuing refused requests for days
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.