fix(processing): Only mark aggregate errors as exception groups#10850
Merged
AbhiPrasad merged 4 commits intodevelopfrom Feb 29, 2024
Merged
Conversation
Contributor
size-limit report 📦
|
AbhiPrasad
approved these changes
Feb 29, 2024
Contributor
AbhiPrasad
left a comment
There was a problem hiding this comment.
Thanks for the PR Katie!
I'll take care of backporting this onto v7.
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
Member
Author
Great, thanks! |
This was referenced Feb 29, 2024
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
