do you catch bugs that don't show up in the logs?
by•
We recently noticed that an API can return a successful response even when the actual update hasn't gone through. The request looked fine but the data wasn't saved and there was no clear error to point us in the right direction.
Now I'm curious how other teams handle this. Do you rely on database checks alerts or some kind of verification after each write? What's worked best for you?
15 views
Replies
What helped me most was making "nothing happened" visible as a state. In my app every song generation is one document with a status, queued, running, done or failed, and the app watches that document. If something silently fails, the song sits in queued, which is easy to spot and easy to query, instead of an absence nobody notices. The other rule: every code path that gives up quietly has to write one plain log line saying that it gave up and why. Reading back after every write sounds safe but gets expensive, so I'd keep that for the writes that involve money. Was it your own API or a third party one?
For an endpoint that promises to update one row, I’d have it return the affected-row count or updated row ID from that same write, and treat zero rows as a failure. Then alert when accepted updates and committed updates diverge. That catches this silent no-op without reading every row back after every request.