[#12779] Don't swallow exceptions in transctional statements

Doug_Barth · November 12, 2013, 12:03pm

Hi,

I have a pull request open for changing the MySQL adapters that I’d love to get reviewed. The gist is the current adapter code swallows all StandardError exceptions, which includes Mysql::Error and Mysql2::Error. During the process of moving over to a multi-master Galera cluster, we found that this behavior was causing our application to returns a successful response even though the database transaction failed to apply. Galera’s replication system is expected to return an error on COMMIT if the transaction failed the certification process. Similarly, it’s possible to have BEGIN fail if you have causal reads enabled and the database times out waiting for queue writesets to be applied.

github.com/rails/rails

Don't swallow exceptions in transctional statements

rails:master ← dougbarth:dont_swallow_exceptions_during_transactional_statements_in_mysql

opened 07:56PM - 05 Nov 13 UTC

dougbarth

+10 -10

The MySQL connection adapater swallows all StandardError exceptions, which inclu…des `Mysql::Error` and `Mysql2::Error`. The comment in the exception clause claims errors thrown here indicate that transactions aren't supported by the server but that isn't necessarily true. It's possible the MySQL server has gone away and swallowing a failed commit may let the application return a successful response when the data has not been saved. Also, replication libraries like Galera require that the application handle exceptions thrown at BEGIN/COMMIT. I'm unable to determine what version of MySQL threw an exception for transactional statements. I tried as far back as 3.23.49 with InnoDB disabled but BEGIN & COMMIT statements do not throw an error. If there's a real case for this logic to continue, we could instead push this behavior into a configuration setting. The exception swallowing has been there since the beginning: db045dbbf60b53dbe013ef25554fd013baf88134 ## Backstory I found this behavior while moving our application to Percona XtraDB Cluster, which uses Galera for synchronous replication. We found a case where a transaction failed the certification process, and therefore threw an exception when COMMIT was called, but the exception was swallowed and the response to the client was an erroneous 200.