Is your argument that the application gracefully recovering from the scenario will somehow make the dev team accommodated?
Hard crashes are not an acceptable substitute for observability, or continuous improvement.
Hard crashes are not an acceptable substitute for observability, or continuous improvement.
This example doesn't even rise to the level of an "active incident" in the Erlang philosophy. In other words, it's not a bug, so there's no urgency to improve it.
Graceful recovery means that something handle that failure after these transactions failed. There is no data loss. They may have been slower, but i think we can agree that a slight temporary latency for no dataloss and graceful handling of unexpected stuff like your database machine being on fire is not so bad?
It's still a bug that should be fixed, it's just that the effects are better contained thanks to the ability to self-heal.