-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
fix(issues): Replace 'Internal Error' message on Postgres query timeout errors #87691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(issues): Replace 'Internal Error' message on Postgres query timeout errors #87691
Conversation
@@ -168,13 +170,12 @@ class FooBarError(Exception): | |||
pass | |||
|
|||
|
|||
class HandleQueryErrorsTest: | |||
class HandleQueryErrorsTest(APITestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this test wasn't running at all from what I can tell since it didnt inherit APITestCase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch!
@patch("sentry.api.utils.ParseError") | ||
def test_handle_query_errors(self, mock_parse_error): | ||
exceptions = [ | ||
DatasetSelectionError, | ||
IncompatibleMetricsQuery, | ||
InvalidParams, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
InvalidParams is not being converted in the actual code, and fails since now I actually run this test. From what I could tell InvalidParams is actually correctly not being converted to a user error since it is sometimes indeed an 'Internal Error' so I removed it from this test (which didnt run until now).
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #87691 +/- ##
==========================================
- Coverage 87.78% 87.75% -0.03%
==========================================
Files 9899 9891 -8
Lines 563493 561770 -1723
Branches 22134 22134
==========================================
- Hits 494675 492995 -1680
+ Misses 68417 68374 -43
Partials 401 401 |
…ut errors Handle Postgres statement timeout errors on issue search which previously displayed 'Internal Error' but will now show more appropriate message explaining the query took too long and to possibly revise it Closes: #80166
ee0dd55
to
5886cc2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense!
…m visible internally A small addition on top of #87691. There we changed it so these errors are now treated as user errors but actually these could possibly come from our own Postgres queries taking too long even on reasonable queries, and without capturing we wouldn't even know they are happening. Even if thats not the case we want to keep these errors visible in Sentry to be able to monitor them.
…m visible internally A small addition on top of #87691. There we changed it so these errors are now treated as user errors but actually these could possibly come from our own Postgres queries taking too long even on reasonable queries, and without capturing we wouldn't even know they are happening. Even if thats not the case we want to keep these errors visible in Sentry to be able to monitor them.
A small addition on top of #87691. There we changed it so these errors are now treated as user errors but actually these could possibly come from our own Postgres queries taking too long even on reasonable queries, and without capturing we wouldn't even know they are happening. Even if thats not the case we want to keep these errors visible in Sentry to be able to monitor them.
A small addition on top of #87691. There we changed it so these errors are now treated as user errors but actually these could possibly come from our own Postgres queries taking too long even on reasonable queries, and without capturing we wouldn't even know they are happening. Even if thats not the case we want to keep these errors visible in Sentry to be able to monitor them.
follow up on #87691, it turns out the organization/issues endpoint actually did not use handle_query_errors and so this fix did not catch. added it now to the endpoint, aligning it with the other endpoints we have there. Also made the catch more specific, as QUERY_CANCELED from postgres are not always timeouts, same code is used for user cancelations, which do not apply to the error message we are converting to. Added endpoint tests as well to cover this.
…#88158) follow up on #87691, it turns out the organization/issues endpoint actually did not use handle_query_errors and so this fix did not catch. added it now to the endpoint, aligning it with the other endpoints we have there. Also made the catch more specific, as QUERY_CANCELED from postgres are not always timeouts, same code is used for user cancelations, which do not apply to the error message we are converting to. Added endpoint tests as well to cover this.
…#88158) follow up on #87691, it turns out the organization/issues endpoint actually did not use handle_query_errors and so this fix did not catch. added it now to the endpoint, aligning it with the other endpoints we have there. Also made the catch more specific, as QUERY_CANCELED from postgres are not always timeouts, same code is used for user cancelations, which do not apply to the error message we are converting to. Added endpoint tests as well to cover this.
Handle Postgres statement timeout errors on issue search which previously displayed 'Internal Error' but will now show more appropriate message explaining the query took too long and to possibly revise it
Closes: #80166