-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(core): Expose prepareEvent
util function
#6517
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
// because `getAttachments` can be undefined if users are using an older version | ||
// of `@sentry/core` that does not have the `getAttachments` method. | ||
// See: https://github.com/getsentry/sentry-javascript/issues/5229 | ||
if (finalScope) { |
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.
Here a small change: Previously, this was:
if( finalScope && finalScope.getAttachments) {
// ...
}
However, that meant that if a scope existed BUT no getAttachments
, it would never run applyToEvent
, which I guess is not desired. cc @AbhiPrasad , or was that on purpose this way?
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 was to guard against cases where user's had different package versions and getAttachments
was not defined on the scope object. This could happen if someone was using captureContext
on a captureException
call that passed in a old scope. This is on purpose, since then attachments didn't exist as a concept on the scope.
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.
Yeah, I get that, what I meant is that we actually guard for all the finalScope
stuff this way, including this:
result = finalScope.applyToEvent(prepared, hint);
Is it desired that this will not be called when finalScope.getAttachments
is not defined?
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.
For future reference: We discussed this internally and IMO we can go with the change and revert this particular part if we get mismatch errors again.
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.
Note: We should still be handling mismatches, unless something inside of scope.applyToEvent
relies on attachments to exists, which I think it shouldn't, as far as I can tell.
packages/replay/jest.setup.ts
Outdated
@@ -15,27 +15,6 @@ jest.mock('./src/util/isBrowser', () => { | |||
}; | |||
}); | |||
|
|||
afterEach(() => { |
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 seems to not be necessary anymore (and actually lead to test issues), so I removed it.
packages/replay/src/replay.ts
Outdated
@@ -947,6 +947,11 @@ export class ReplayContainer implements ReplayContainerInterface { | |||
|
|||
const replayEvent = await getReplayEvent({ scope, client, replayId, event: baseEvent }); | |||
|
|||
if (!replayEvent) { |
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.
We actually did not handle this case before (I guess types can be helpful after all xD), which can be the case when using an event processor.
size-limit report 📦
|
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 from the replay side of things
packages/replay/src/replay.ts
Outdated
@@ -947,6 +947,11 @@ export class ReplayContainer implements ReplayContainerInterface { | |||
|
|||
const replayEvent = await getReplayEvent({ scope, client, replayId, event: baseEvent }); | |||
|
|||
if (!replayEvent) { | |||
__DEBUG_BUILD__ && logger.log('[Replay] Event was dropped.'); |
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.
How do we handle other events when they get dropped?
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 happens here:
this.recordDroppedEvent('event_processor', event.type || 'error', event); |
I guess we could also use recordDroppedEvent
here 🤔 I'll give it a look!
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 updated this to also record dropped replay events, and left a comment as well referencing where this is taken from!
b74d9ab
to
d1d9acf
Compare
d1d9acf
to
e4ef56e
Compare
Note: I've actually split this into two PRs, one where we expose this, and #6522 where we start using this in replay. |
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!
e4ef56e
to
18f2623
Compare
So we can use this in replay, instead of using a private method from the client.
Also added a test to replay to make sure event processors work properly (which they didn't really before).