-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
feat(scope): Bring back lastEventId
on isolation scope (#11951)
#12022
Conversation
lastEventId
on isolation scope (#11951)
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.
Great! Just had two comments but looking good!
packages/core/src/baseclient.ts
Outdated
const eventId = event.event_id || hint.event_id; | ||
if (eventId) { | ||
isolationScope.setLastEventId(eventId); | ||
} |
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.
m: I think we pass all kinds of events through _prepareEvent
right? Before removing this function, we only updated the last event id for error events. I'd argue we should do the same now.
see
sentry-javascript/packages/core/src/hub.ts
Lines 396 to 398 in 90b45f0
if (!event.type) { | |
this._lastEventId = eventId; | |
} |
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.
Yea, everything goes through that, including captureMessage
and captureEvent
. I aligned this change to the Python SDK (ref: getsentry/sentry-python#3064) where they also store it for any event.
The name kind of sounds to me like it would really contain any event, not just errors, but I can change it to just errors, wdyt?
cc @mydea
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.
Sorry, I think I worded this incorrectly. I'm totally fine with error and message events that's all good. They all have event.type === 'undefined'
.
As for Replay or transaction/span events, these also go through _prepareEvent
but they have a different event.type
. I woudn't update lastEventId for them because
- then users will much more likely get completely unexpected
lastEventId
return values. For example, a transaction could end right between the error being captured and users callinglastEventId
--> the return value would return the transaction event id. - previous behaviour was also to not update the id for these events.
I agree, naming-wise lastEventId
implies any event but this has historic reasons. This API probably existed long before we decided to send spans/transactions and also treat them as events with a different type.
Happy to be overruled but I think we should consider at least point 1
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 agree with lukas, that makes the most sense to me too! :)
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.
@Lms24 fixed. Thanks for the explanation, I assumed too much what an Event is :)
Co-authored-by: Lukas Stracke <[email protected]>
f85d369
to
2e387fc
Compare
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.
Great, thanks!
…2022) Co-authored-by: Lukas Stracke <[email protected]>
As discussed, we'll keep it simple and set the event id regardless of the event getting dropped.
A follow-up PR will update
ReportDialogOptions
to makeeventId
optional again as well as use the isolation scope directly in React ErrorBoundaries.