The Error Handler That Ate The Errors

The whole point of the change was to make failure loud. It stayed silent, and that took me most of an afternoon to accept.

In BandOS I wired a global rule into the data-fetching layer so any failed request would throw up to an error boundary. I wanted a broken load to shout, not shrug.

It did not behave the way the docs implied. I rerouted a request to a dead endpoint, watched it 404 twice (once for the retry), and the page calmly rendered its empty state. No error screen. The query had genuinely failed, and the throw-on-error flag never carried it to the boundary.

Here is why that matters. For a band using the app, an empty list and a broken request looked identical. “You have no upcoming decisions” and “we could not load your decisions” drew the same blank page. One is a fact. The other is a failure quietly pretending to be one. Someone could log in, see nothing, and trust it.

The fix was to stop leaning on the throw and listen one level down instead: a single handler on the query cache that fires a toast whenever any query errors. I believed it because it is the exact mechanism already working elsewhere for writes, where I had watched the toast fire with my own eyes.

A safety net you have never seen catch anything is just decoration. Test the net by falling into it.