A user reported that a feature had stopped working. Classic regression report: "we used to have X, now it's gone." So I did what you do. I opened the git log, found the refactor that touched that area, and started reading diffs looking for the commit that removed it.
I spent an afternoon proving a negative.
Nothing had removed it. The behavior had been specified, discussed in an issue, and referenced in a PR description as done. But the code path never existed in the new component. It had been built in the old implementation, and when the new one was written behind a flag, that particular piece sat on someone's hand-written parity checklist and quietly never got ticked.
The part I keep thinking about is how the framing picked my strategy for me. The word "regression" carries an assumption: that the thing existed and then stopped existing. Accept that assumption and you reach for git bisect, git log, blame. Reject it and you reach for grep. One of those answers the question in ten seconds and the other burns an afternoon.
What made it worse is that a hand-written parity checklist is not a diff. Someone listed the features they thought needed porting, and the list was incomplete, which is the normal state of hand-written lists. A green test suite did not help either, because nobody writes a test for a thing that was never built.
So now the first thing I do with any regression report is grep the current code for the behavior. If it is not there, I stop looking for who deleted it and start asking whether it ever shipped. It costs ten seconds and it has saved me twice since.
A bug report describes a symptom. It is not a diagnosis, even when it sounds like one.
Top comments (0)