Most these issues seem specific to, and created by, the impedance mismatch between ORMs (like ActiveRecord) and databases. To work correctly, application code

Most these issues seem specific to, and created by, the impedance mismatch between ORMs (like ActiveRecord) and databases. To work correctly, application code must be aware of transactions, and be prepared to roll back state and safely retry a transaction on failure. ORMs like ActiveRecord struggle to do this because they attempt to present a transactional database as a low-friction, in-memory, mutable, non-transactional data model that does not support rollback. If you lose a connection to the database prior to successfully committing your transaction, this is just another form of transaction failure. You need to discard any pending application state changes, open a new connection and transaction, requery data required to determine the actual current state, and then if necessary, retry your transaction. ActiveRecord can’t do that, hence the ill-advised desire to be able to automatically retry statements on failure — which abandons database-mediated transaction isolation, and incorrectly shifts responsibility for database state preservation/management to the client. If SQL was trivially idempotent, we wouldn’t need transactions or different levels of transaction isolation in the first place.