A fallback that fired every time
Our internal ideas board labelled every post with the author email address instead of their name. The code asked for a field that does not exist, so the emergency fallback ran on every single request, for as long as the feature had existed.
We keep an ideas board inside the product — one shared list where any operator can suggest something, vote on somebody else's suggestion and see what we have picked up. It is deliberately not split per venue. The whole value is that a kitchen in one hall can see that four kitchens elsewhere want the same thing.
The line of code that decided what name to put on a post read, in effect: use their display name; if there isn't one, use their email address; if there isn't one of those either, say "Somebody".
That reads like a sensible ladder. It was not, because it asked for the wrong field. The name a person chooses is stored under one label and the code asked for a different one. The first rung did not exist.
So the second rung was the only rung
Every idea, every comment, and the little "posting as…" line at the top of the board carried an email address. Not occasionally — always, for as long as the feature had been there. And because the board is shared across every venue on the platform, an operator in one hall would have seen the address of an operator in another.
The chosen name was sitting in the database the entire time, untouched.
Why nothing caught it
A fallback that fires occasionally gets noticed, because somebody eventually sees the odd-looking case and asks. A fallback that fires every time looks like the design. Anyone glancing at that board would have concluded we had decided to label posts by email, and moved on.
This is worth carrying into any system you run. When you see a default value everywhere — every supplier showing "Unknown", every shift showing "Staff", every line showing the same placeholder — the useful question is not "why is this one wrong?" It is "is anything ever not the default?" If the answer is no, the thing that should be filling it in is not connected.
The same mistake in four other places, and two that only looked like it
Having found it once, we searched for the pattern. It appeared in four more places: who sent a stock transfer, who received it, who raised a purchase requisition, who approved it. All four wrote into a column whose entire job is to hold a person's name, and all four had been storing an address.
Two more places looked identical in a text search and were not — they fetch the name under a renamed label, so the field really is the display name there. Acting on the search result alone would have broken two working screens in the course of "fixing" them. The five-minute check that separates those cases is the whole difference between a fix and an outage.
One deliberate inconsistency
Those four internal records keep the email as a last resort. They are attributions inside one venue, read by colleagues who already have the address, and a stock transfer with nobody's name against it is worse than one with an address on it.
The shared ideas board does not. If we do not know your name there, it says "Somebody" — because a board read by every operator on the platform is not the place to reach for the one field on your account you would least like printed next to your opinions.
That difference is a judgement, not an oversight, which is why it is written down in the code next to both.