Uh oh!
There was an error while loading. Please reload this page.
feat(core): Add replay_event type for events - #6481
Conversation
| public captureEvent(event: Event, hint?: EventHint): string { | ||
| const eventId = hint && hint.event_id ? hint.event_id : uuid4(); | ||
| if (event.type !== 'transaction') { | ||
| if (!event.type) { |
There was a problem hiding this comment.
Question: I guess replays should not count here? (Eventually - currently they do not go through this method at all)
There was a problem hiding this comment.
We might also add a test for the new event type here:
sentry-javascript/packages/hub/test/hub.test.ts
Lines 360 to 373 in c68d429
71839e0 to
2a68ccfComparesize-limit report 📦
|
| public captureEvent(event: Event, hint?: EventHint): string { | ||
| const eventId = hint && hint.event_id ? hint.event_id : uuid4(); | ||
| if (event.type !== 'transaction') { | ||
| if (!event.type) { |
| public captureEvent(event: Event, hint?: EventHint): string { | ||
| const eventId = hint && hint.event_id ? hint.event_id : uuid4(); | ||
| if (event.type !== 'transaction') { | ||
| if (!event.type) { |
There was a problem hiding this comment.
We might also add a test for the new event type here:
sentry-javascript/packages/hub/test/hub.test.ts
Lines 360 to 373 in c68d429
| // TODO: Handle replay_event here | ||
| // Currently, this is done by replay, but we want to upstream this here | ||
| const eventType = event.type && event.type !== 'replay_event' ? event.type : 'event'; |
There was a problem hiding this comment.
To note, this is technically correct, but may increase the bundle size slightly for "nothing", as this will not really be hit right now. I'd still rather leave this in and remove it once we (hopefully soon!) actually handle replay events "normally". WDYT?
37535a0 to
4e35eb8Compare| // Only tag transactions with replayId if not waiting for an error | ||
| // @ts-ignore private | ||
| if (event.type !== 'transaction' || !replay._waitForError) { |
There was a problem hiding this comment.
To be explicit that we only want this when the event is an error. This is IMHO more future proof, as when/if we add further event types, we'll need to explicitly handle them.
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
4e35eb8 to
0e74f6aCompare0e74f6a to
4e87368Compare
As a first step for #6480, this adds the replay event type.
Note that replay is a bit special, in that it has two event types:
replay_eventandreplay_recording. These are sent in one envelope, wherereplay_eventcontains the replay metadata etc, andreplay_recordingthe actual recording as string.IMHO for the
eventtype we have here it is sufficient to havereplay_event, as thereplay_recordingis not really passed around but only need to be considered when we (eventually) build the envelope.