Reading about the situation raises all kinds of alarms / questions regarding the testsuite being used and/or the way the devs "fix" bugs. Many companies, it seems, have those incompetent coders who are apparently so used to wading through muddy water that they don't understand, that they also don't care to really tackle a bug when one is found: instead of going to the bottom with full analysis and a robust fix, they take the much shorter route of coming up with a "hack" or "kludge" that isn't understood but (seems to) work(s); aka, the testsuite stopped complaining. (Note: only when then resulting code is 1. actually correct, 2. nobody understands it, you could speak of "black magic" or "voodoo coding" (waving a dead chicken), but that is clearly not what we're talking about here).
The picture here is that "random" things are tried until the testsuite doesn't give an error anymore. This sounds stupid, and it is, but it happens sadly a lot.
(Note: the result is they make the deadline every time, but create a source tree like a house of cards. Unmaintainable, because nothing makes sense or does what it says. Unflexible, because any change reveals a dozen or so bugs that before the change were cancelling eachother out mostly (in the case of two bugs, two easy to find bugs (or rather, one bug and one "fix") are turned into one hard-to-find and obscure bug: so hard that Q&A and the testsuite don't run into it, it can't be reproduced and only happens in rare conditions in the production environment. I know, because then the good coders (or coder if said company only has one) are asked to look into it :/.
If such a top coder exists, and he is able to find the problem, and good version control exists, then in the end the problem will be described as: "there was (obscure, whatever) bug in xyz, which was partly fixed in commit ef576c2 but did not really address the real issue".
In the meantime a LOT time was wasted, but it isn't the place of this good coder to describe it as: "A Johnson fuckup as usual. When is that guy finally going to be fired?"
Evolutionary this seems to be something that keeps itself alive however: making deadlines and providing a product with cheap coders (that aren't offered high salaries elsewhere anyways) for a while, and then ending up with a product that constantly needs "maintenance", aka keeps bringing in money after the client has already become dependent on it, or invested too much into, seems to work better then the same application that costs four times as much and takes twice as long to deliver (but never fails).
Hence, reading your description: "Luck" (jokingly) when it was the same coder, or else I'd call it "someone's stupidity".