← All updates
AUG 27 · 2026
CHANGELOG

When something breaks, a person wrote the sentence

Five of our routes ended the same way. Something went wrong, the code caught the error, and it put that error's own message in the response — which the booking page then displayed to whoever was standing there trying to book.

Most of the time that is merely unhelpful. Twice it was worse. One client was shown a sentence naming an internal pricing rule by its identifier and instructing a developer to migrate the provider's account. Another was shown the verification provider's own error text, verbatim. Neither person was a developer. Both were trying to book an appointment.

The obvious repair is to look for the bad phrases and strip them. We did not do that, and the reason is the whole point: stripping known-bad text fixes exactly the messages someone has already seen and leaks the next one. Every future error anywhere beneath those routes — ours or a vendor's — would be a new candidate, and nobody would find out until it appeared on a client's screen.

So nothing derived from a caught error reaches a response at all. The only text that goes out is a sentence written at the point in the code where a human decided what a person in that situation ought to be told, and where a reviewer can read it before it ships. The real error still exists; it goes to the log with its context, which is where whoever has to fix it will look.

Your clients see the failure. They should not have to see the plumbing.

NEW· 1
Booking pageEvery payment and verification route answers a failure with an authored sentence; the real error goes to the log with its context.
FIXED· 1
Booking pageA client booking an appointment can no longer be shown an internal rule identifier, or a payment provider's own error text, as the explanation for why something did not work.