The Ticket We Closed Twice For The Same Bug

You already trust a status you shouldn’t.

Your registration platform says an email was “sent.” Your check-in app says a badge “synced.” Your payment provider says a refund was “processed.” None of those words describe what happened to the attendee. They describe that a system reached the point in its own code where it is allowed to say that word.

Whether the email landed in an inbox, whether the badge scan actually recorded, whether the money moved: that’s a different question, and most tools don’t ask it before reporting success.

Most of the time the gap doesn’t matter. The email did land. The badge did sync. Then, once in a while, it doesn’t, and the first anyone hears about it is an attendee at your check-in desk asking why the system says they’re not on the list.

What does a “fixed” ticket actually confirm?

We had our own version of this three weeks ago, in the machinery that ships Presso Events, not the part any organiser sees.

Our deploy pipeline covers six environments. One of them is production.

A while back, a bug in that pipeline meant the deploy jobs never ran at all. A broken reference in the workflow file stopped every job before it started. Silent, total, nothing shipping anywhere.

Someone found it, fixed the broken reference, and the jobs started running. Ticket closed as fixed. And it was fixed - that specific bug, the one that had been reported, was genuinely gone.

What nobody checked afterwards was whether a deploy had actually happened. It hadn’t. The jobs now ran, hit the very next step, and failed immediately: a credential the deploy needs had never been added to the repository. Six environments, all failing at the same wall, production included.

Zero deploys before the fix. Zero deploys after the fix. Two entirely different bugs produced the identical outcome, and the ticket had already been closed once in between.

We found the second bug the way most people find this class of problem: not because anyone went looking for it, but because a routine monitoring pass happened to notice the workflow was red. Nobody had needed to ship anything urgently enough to go and check themselves, which is the only reason it stayed comfortable for as long as it did.

Why does “the error went away” feel like proof?

Because closing a ticket is usually the right instinct. The error was reproduced, understood, and stopped. By the ticket’s own definition, the work was done correctly.

The thing the ticket never asked is the thing that actually mattered: did the outcome resume? Not “does the error still appear” but “has the thing this was supposed to produce actually been produced since.” Those are different questions, and only one of them was on the ticket.

You have a version of this open right now. A “resolved” item somewhere in your own tracker, closed because the symptom stopped, that nobody reconfirmed against the actual result. I’d bet on it.

It’s an easy trap because the two questions look identical from the ticket’s point of view. “Error gone” and “outcome present” both read as green. They only diverge when a second, unrelated fault is standing exactly where the first one used to be, and it takes an actual look at the outcome, not the error log, to tell them apart.

The check that would have caught it

Not a better monitoring tool. A different question, asked at the point of closing anything: can I point at the actual thing, not the report about the thing?

For a deploy, that’s a timestamp on the live page, not a green run in the workflow list. For a confirmation email, that’s a delivered message in an inbox, not a “sent” status in a dashboard. For a badge scan, that’s an attendee walking through the door, not a sync counter ticking up.

None of those checks are hard. They’re just a different place to look, and they’re usually one click further than the status that already told you what you wanted to hear.

The fix on our side was small: the deploy pipeline now checks that a live page actually changed before it calls itself done, not just that the job exited without an error. It’s a worse story than “we added better monitoring.” It’s closer to “we finally checked the thing instead of the report about the thing,” which is a less impressive sentence and a more useful habit.