Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDon't translate non-database exceptions. #29692
Conversation
rails-bot
assigned
matthewd
Jul 6, 2017
This comment has been minimized.
This comment has been minimized.
rails-bot
commented
Jul 6, 2017
|
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") |
This comment has been minimized.
This comment has been minimized.
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 comment has been minimized.
This comment has been minimized.
eugeneius
reviewed
Jul 6, 2017
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. |
This comment has been minimized.
This comment has been minimized.
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_recordnotification subscribers from being converted intoActiveRecord::StatementInvalidexceptions.
| ActiveSupport::Notifications.unsubscribe(subscriber) if subscriber | ||
| end | ||
| def test_other_exceptions_are_translated_to_statement_invalid |
This comment has been minimized.
This comment has been minimized.
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.
| def syntax_error_exception_class | ||
| return Mysql2::Error if defined?(Mysql2) | ||
| return PG::SyntaxError if defined?(PG) | ||
| return SQLite3::SQLException if defined?(SQLite3) |
This comment has been minimized.
This comment has been minimized.
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 comment has been minimized.
This comment has been minimized.
fimmtiu
Jul 7, 2017
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!
fimmtiu
added some commits
Jul 7, 2017
matthewd
merged commit e5bcc7b
into
rails:master
Jul 8, 2017
This comment has been minimized.
This comment has been minimized.
|
This looks great, thanks! |
fimmtiu commentedJul 6, 2017
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.