-
-
Notifications
You must be signed in to change notification settings - Fork 8
feat: add InvokeSentryResult::Events() to extract events from envelopes
#137
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
Conversation
|
| } | ||
| } | ||
| } | ||
| catch { } |
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.
Why do we need to swallow exceptions here? If it's because of the access to event_id, you could use for example $header | Select-Object -ExpandProperty event_id -ErrorAction SilentlyContinue or $header.PsObject.Properties['event_id']?.Value
| $header = $lines[0].Trim() | ConvertFrom-Json | ||
| if ($header.event_id -and $ids -notcontains $header.event_id) | ||
| { | ||
| $body = $lines | Select-Object -Skip 1 | Where-Object { |
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.
This assumes single event in an envelope - is that OK?
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.
I think so. According to the docs, "event" items may occur at most once per envelope: https://develop.sentry.dev/sdk/data-model/envelope-items/#event
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.
LGTM with some questions. Consider logging in catch blocks as well as when an event is being skipped because another one has the same ID
NOTE: requires latest github-workflows: getsentry/github-workflows#137
This PR provides a solution to the problem described in
Problem
Sentry.NET integration tests run Android apps twice:
SentrySDK.CauseCrash(CrashType.Java). It might succeed in sending the crash envelope to Sentry right away, or hit a timeout and leave the envelope cached on disk.The problem is that the request from the first run might go through to the server, while the client hits a timeout and quits before receiving a response back. In this case, the second run sends the cached envelope again. While a real Sentry server would discard the duplicate, the test server records both, causing test assertions to fail.
Solution
InvokeSentryResult::Events()extracts unique event payloads from envelopes.