fix(processing): Only mark aggregate errors as exception groups #10850
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size-limit report 📦
|
AbhiPrasad
approved these changes
Feb 29, 2024
AbhiPrasad
deleted the
kmclb-stop-considering-linked-errors-exception-groups
branch
AbhiPrasad
pushed a commit
that referenced
this pull request
Feb 29, 2024
When Sentry started supporting the idea of exception groups, two changes happened. In the SDK, we adapted our logic for handling linked errors to also handle `AggregateError`s. And in our ingest pipeline, we began looking for an `is_exception_group` flag on the last entry in `event.exception.values; when we found it, we'd then ignore that entry when grouping and titling events, under the assumption that it was just a container and therefore wasn't meaningful. When it came to instances of `AggregateError`, this worked great. For linked errors, however, this caused us to focus on the `cause` error rather than the error which was actually caught, with the result that it both threw off grouping and made for some very unhelpful titling of issues. (See the screenshot below, in which the first three errors are, respectively, an `UndefinedResponseBodyError`, a `RequestError`, and an `InternalServerError`, though you'd be hard pressed to figure that out without opening them up.) This fixes those problems by restricting the use of the `is_exception_group` flag to `AggregateError`s. Note: In order to update the tests to work with this change, I had add in consideration of the error `name` property and the corresponding event `type` property, to match what we do in real life. To keep things readable, there's a new mock `AggregateError` class, which I adapted all the tests to use.
This was referenced Feb 29, 2024
Closed
Great, thanks! |
This was referenced Feb 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When Sentry started supporting the idea of exception groups, two changes happened. In the SDK, we adapted our logic for handling linked errors to also handle
AggregateErrors. And in our ingest pipeline, we began looking for anis_exception_groupflag on the last entry in `event.exception.values; when we found it, we'd then ignore that entry when grouping and titling events, under the assumption that it was just a container and therefore wasn't meaningful.When it came to instances of
AggregateError, this worked great. For linked errors, however, this caused us to focus on thecauseerror rather than the error which was actually caught, with the result that it both threw off grouping and made for some very unhelpful titling of issues. (See the screenshot below, in which the first three errors are, respectively, anUndefinedResponseBodyError, aRequestError, and anInternalServerError, though you'd be hard pressed to figure that out without opening them up.)This fixes those problems by restricting the use of the
is_exception_groupflag toAggregateErrors.Note: In order to update the tests to work with this change, I had add in consideration of the error
nameproperty and the corresponding eventtypeproperty, to match what we do in real life. To keep things readable, there's a new mockAggregateErrorclass, which I adapted all the tests to use.Fixes getsentry/sentry#59679.
These issues all look the same, but they are not, in fact, the same
