The error that blamed your dish
Four different situations, one error message: "the dish has changed since it was made". It was true in one of them. Why an error that names the wrong cause is worse than one that admits it does not know.
In the tool that proposes allergen information for a dish, there is a moment where you press "accept" and the thing you were accepting is no longer there. The system handled that properly — it refused, rather than writing allergens off a stale screen. Refusing was right.
What it said while refusing was: "That suggestion is no longer current — the dish has changed since it was made. Ask again."
There are four ways to arrive at that moment, and the dish having changed is one of them. The others: somebody already accepted it, somebody already rejected it, or there was never a suggestion for that dish in the first place. All four got the same sentence.
Why the wrong reason is worse than no reason
"Something went wrong, try again" is a poor message, but it is honest about its own ignorance and it sends nobody anywhere.
"The dish has changed" is a specific, actionable, confident instruction to go and look at a dish. If the dish has not changed, that instruction wastes somebody a trip — and in this particular corner of the product, the thing they are being sent to re-check is an allergen line. This is the one area where we work hardest to say exactly what we know and how we know it. Sending a chef to re-examine a peanut declaration on a recipe nobody has touched is the most expensive wrong sentence this product can print.
How it happens
Not through carelessness. It happens because the first version of the feature genuinely had one failure case, and the sentence was written for it and was correct. Then three more paths grew into the same place, each one passing through a check that already had a message attached. Nobody chose to blame the dish three extra times. Each addition simply inherited a sentence that used to be true.
This is the ordinary way error messages rot. They do not start wrong. They start specific, and then the code around them generalises while the words stay put.
What to look for in your own systems
If you have a message that appears in a variety of unrelated situations, treat it as suspect. The tell is usually reported by staff rather than found in code: "it says X but that is not what happened" said more than once about the same message is a strong signal that the message has outlived its one true case.
The same applies to messages your suppliers and platforms send you. A delivery platform that says "item unavailable" when the real cause is a menu sync failure will have you counting stock you already have.
Four situations, four sentences
The fix is not clever. The code now looks at what actually happened and says one of four things: the dish has changed, it was already accepted, it was rejected, or there is nothing waiting for this dish yet. Each one tells you what to do next, and only one of them sends you to the dish.
The single-sentence version was fewer lines of code, and the cost of those saved lines was paid by whoever went and stared at a recipe that was fine.