There's a category of bug that's almost invisible until you're the one staring at it — the kind where something just doesn't go away when it should.
The problem
In a booking management interface used by travel agents, there's a notification banner that warns agents when they're looking at a booking retrieved from a queue. The intent is clear: flag that this record came from a queue, not from a direct lookup. Once the agent has retrieved the record and the context changes, the banner should disappear.
It wasn't disappearing.
After retrieving a booking from the queue and moving on, the warning banner stayed visible — persisting across view transitions, sitting silently in the terminal in a state that no longer applied. Nothing was broken in the functional sense. Fares could still be searched, bookings could still be modified. The banner was just wrong.
Why these bugs are easy to ship
A lingering notification doesn't fail a unit test. It doesn't throw an error or cause a traceable exception. It simply stays on screen past its welcome, and the only way to catch it is to manually walk through the interaction flow and notice that something feels off.
Tests tend to verify that things happen — components render, events fire, state updates. They're less good at verifying that things stop happening at the right moment. A banner appearing is testable. A banner not appearing after a specific sequence of interactions requires a test that explicitly asserts absence after a lifecycle transition, which is the kind of test that often gets skipped because "it's just UI state".
Except for agents using this tool all day, it's not just UI state. A notification that outlives its context creates a small but persistent cognitive load: is the queue state still relevant? Did something go wrong? Should I be worried? The interface is lying, quietly, in a way that erodes trust.
The fix
The root cause was that the notification state wasn't being cleared on the correct lifecycle event. When the booking was retrieved from the queue, the flag that triggered the banner was set. When the user transitioned away from that context, the flag wasn't being reset — it just carried forward into the next view.
The fix was to wire the dismissal to the right transition point: when the queue retrieval context is left behind, clear the notification state. Once that connection was made, the banner behaved correctly — appearing when relevant, disappearing when not.
The broader pattern
This is a recurring shape in UI work on long-lived, stateful applications. State accumulates. Things that were true in one context bleed into the next if you're not deliberate about cleanup. It's especially common in applications built incrementally over years, where the component that sets a flag and the component that should clear it aren't obviously connected, and the original author of each may not have anticipated how they'd interact.
The fix for any individual instance is usually small. The harder problem is building the habit of thinking about state exit conditions as carefully as state entry conditions — asking not just "when should this appear?" but "when should this definitively stop appearing, and am I certain that's covered?"
Most of the time the answer is yes, and nothing bad happens. Occasionally it isn't, and you end up with a warning banner haunting a terminal long after the thing it was warning about has resolved.