Skip to content

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

Merged
merged 1 commit into from
Mar 24, 2025

Conversation

yuvmen
Copy link
Member

@yuvmen yuvmen commented Mar 24, 2025

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

@yuvmen yuvmen added the WIP label Mar 24, 2025
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Mar 24, 2025
@@ -168,13 +170,12 @@ class FooBarError(Exception):
pass


class HandleQueryErrorsTest:
class HandleQueryErrorsTest(APITestCase):
Copy link
Member Author

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

Copy link
Member

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,
Copy link
Member Author

@yuvmen yuvmen Mar 24, 2025

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).

Copy link

codecov bot commented Mar 24, 2025

Codecov Report

All 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
@yuvmen yuvmen force-pushed the yuvmen/improve-postgres-query-timeout-messaging branch from ee0dd55 to 5886cc2 Compare March 24, 2025 21:24
@yuvmen yuvmen removed the WIP label Mar 24, 2025
Copy link
Member

@JoshFerge JoshFerge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense!

@JoshFerge JoshFerge requested a review from a team March 24, 2025 21:43
@yuvmen yuvmen merged commit 339fc4f into master Mar 24, 2025
47 checks passed
@yuvmen yuvmen deleted the yuvmen/improve-postgres-query-timeout-messaging branch March 24, 2025 22:06
yuvmen added a commit that referenced this pull request Mar 25, 2025
…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.
yuvmen added a commit that referenced this pull request Mar 26, 2025
…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.
yuvmen added a commit that referenced this pull request Mar 26, 2025
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.
andrewshie-sentry pushed a commit that referenced this pull request Mar 27, 2025
…ut errors (#87691)

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
andrewshie-sentry pushed a commit that referenced this pull request Mar 27, 2025
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.
yuvmen added a commit that referenced this pull request Mar 27, 2025
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.
yuvmen added a commit that referenced this pull request Mar 28, 2025
…#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.
andrewshie-sentry pushed a commit that referenced this pull request Mar 31, 2025
…#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.
@github-actions github-actions bot locked and limited conversation to collaborators Apr 9, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Backend Automatically applied to PRs that change backend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve issue stream errors
2 participants