Don't translate non-database exceptions. #29692
Conversation
The AbstractAdapter will translate all StandardErrors generated during the course of a query into ActiveRecord::StatementInvalids. Unfortunately, it'll also mangle non-database-related errors generated in ActiveSupport::Notification callbacks after the query has successfully completed. This should prevent it from translating errors from ActiveSupport::Notifications.
|
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review. Please see the contribution instructions for more information. |
| @@ -211,6 +211,28 @@ def test_numeric_value_out_of_ranges_are_translated_to_specific_exception | |||
| end | |||
| end | |||
|
|
|||
| def test_exceptions_from_notifications_are_not_translated | |||
| original_error = RuntimeError.new("This RuntimeError shouldn't get translated") | |||
eugeneius
Jul 6, 2017
Member
This test passes even on master, because a RuntimeError is never translated:
https://github.com/rails/rails/blob/v5.1.2/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L622-L623
This test passes even on master, because a RuntimeError is never translated:
https://github.com/rails/rails/blob/v5.1.2/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L622-L623
fimmtiu
Jul 6, 2017
Author
Contributor
(facepalm) You're quite right. Fixed! Sorry about that.
(facepalm) You're quite right. Fixed! Sorry about that.
|
I'm nitpicking a lot here, but overall this is a good change - thank you for working on it |
| @@ -1,3 +1,8 @@ | |||
| * Prevent AbstractAdapter from converting exceptions from ActiveSupport::Notification | |||
| callbacks into ActiveRecord::StatementInvalids. | |||
eugeneius
Jul 6, 2017
Member
There's no need to mention AbstractAdapter here, it's an implementation detail.
We should include the name of the notification event that was affected (sql.active_record).
References to constants, methods or options should be wrapped in backticks.
Putting it all together 💅 :
Prevent errors raised by sql.active_record notification subscribers from being converted into ActiveRecord::StatementInvalid exceptions.
There's no need to mention AbstractAdapter here, it's an implementation detail.
We should include the name of the notification event that was affected (sql.active_record).
References to constants, methods or options should be wrapped in backticks.
Putting it all together
Prevent errors raised by
sql.active_recordnotification subscribers from being converted intoActiveRecord::StatementInvalidexceptions.
| ActiveSupport::Notifications.unsubscribe(subscriber) if subscriber | ||
| end | ||
|
|
||
| def test_other_exceptions_are_translated_to_statement_invalid |
eugeneius
Jul 6, 2017
Member
"Other exceptions" is a bit vague - we should specify that this test covers errors raised by the adapter when attempting to execute the query.
"Other exceptions" is a bit vague - we should specify that this test covers errors raised by the adapter when attempting to execute the query.
| def syntax_error_exception_class | ||
| return Mysql2::Error if defined?(Mysql2) | ||
| return PG::SyntaxError if defined?(PG) | ||
| return SQLite3::SQLException if defined?(SQLite3) |
eugeneius
Jul 6, 2017
Member
This covers the three in-tree adapters, but it feels brittle to return nil by default here. I know that the oracle-enhanced adapter runs the Active Record test suite to verify their implementation; this test will break for them.
Do we need to verify the class of the wrapped exception? Is it realistically possible for the assertion to fail (since Ruby is setting the exception's cause automatically)?
This covers the three in-tree adapters, but it feels brittle to return nil by default here. I know that the oracle-enhanced adapter runs the Active Record test suite to verify their implementation; this test will break for them.
Do we need to verify the class of the wrapped exception? Is it realistically possible for the assertion to fail (since Ruby is setting the exception's cause automatically)?
fimmtiu
Jul 7, 2017
Author
Contributor
I agree that it feels brittle, and I'm not terribly happy with it. I thought it would be valuable to make sure that the StatementInvalid's cause is set to the original exception which caused the error, because I was remembering how StatementInvalid used to store the original exception itself back in 4.2. Looking at 5.x, however, it seems like it just relies on Ruby's nested exceptions now, so I guess we don't need to test this at all.
Anyhow, I couldn't find a convenient way to make execute throw a reliable exception which we could test for, so I went with the hard-coded exception classes. Well, that's not quite true. If you do execute(nil) it'll throw a TypeError under MySQL and SQLite3, but that's driver-specific behaviour which seems even worse to depend upon, because the dependency is implicit rather than explicit. (Didn't test the PG adapter.)
Sounds like the best approach is to just test for the presence of cause and not look any deeper at it. I'll do that for the moment; let me know if you have a better suggestion.
Thanks very much for the feedback!
I agree that it feels brittle, and I'm not terribly happy with it. I thought it would be valuable to make sure that the StatementInvalid's cause is set to the original exception which caused the error, because I was remembering how StatementInvalid used to store the original exception itself back in 4.2. Looking at 5.x, however, it seems like it just relies on Ruby's nested exceptions now, so I guess we don't need to test this at all.
Anyhow, I couldn't find a convenient way to make execute throw a reliable exception which we could test for, so I went with the hard-coded exception classes. Well, that's not quite true. If you do execute(nil) it'll throw a TypeError under MySQL and SQLite3, but that's driver-specific behaviour which seems even worse to depend upon, because the dependency is implicit rather than explicit. (Didn't test the PG adapter.)
Sounds like the best approach is to just test for the presence of cause and not look any deeper at it. I'll do that for the moment; let me know if you have a better suggestion.
Thanks very much for the feedback!
|
This looks great, thanks! |
The error thrown might have changed due to rails/rails#29692
The error thrown might have changed due to rails/rails#29692
The error thrown might have changed due to rails/rails#29692
Summary
The AbstractAdapter will translate all StandardErrors generated during the course of a query into ActiveRecord::StatementInvalid exceptions. Unfortunately, it'll also mangle non-database-related errors generated in ActiveSupport::Notification
sql.active_recordcallbacks after the query has successfully completed.This patch should prevent it from translating errors from ActiveSupport::Notifications. All it does is move the
rescuethat translates exceptions into StatementInvalids inside theinstrumentblock, so that it only affects the database code instead of the entire ActiveSupport::Notification block. Threw in a couple of tests for good measure.This actually bit us in a real use case recently; we use
sql.active_recordnotifications to notify and/or throw exceptions for queries that run too long, and the exceptions were coming out as ActiveRecord::StatementInvalid instead of our custom LongQueryError exception type.