Skip to content

Conversation

@billyvg
Copy link
Member

@billyvg billyvg commented Jan 4, 2023

Moves replayType from tags to part of replay_event.

Added in backend in https://github.com/getsentry/replay-backend/issues/210

Moves `replayType` from tags to part of `replay_event`.

Added in backend in getsentry/replay-backend#210
billyvg added a commit that referenced this pull request Jan 4, 2023
@billyvg billyvg marked this pull request as ready for review January 5, 2023 02:01
@billyvg billyvg requested review from Lms24 and mydea January 5, 2023 02:01
Copy link
Member

@mydea mydea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Just had some thoughts while going through this PR but they're more food for thought than change requests :D LGTM!

Comment on lines 62 to +63
replayEventPayload: expect.objectContaining({
replay_type: 'error',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as a side note: I'm not too happy about assertions like expect.objectContaining because they don't catch certain kinds of changes to the object under test. In this example, when we add a field, we need to specifically look up these tests and add them to cover the new field. Also, if we "accidentally" add a field, this assertion wouldn't catch it. If we just use "hard" comparisons, I think we could increase the robustness of these tests, as they would fail automatically. It's not something we have to change right now but I think, we should keep it in mind going forward.

sdk: { integrations: ['BrowserTracing', 'Replay'], name: 'sentry.javascript.browser', version: '7.25.0' },
segment_id: 3,
tags: { errorSampleRate: 0, replayType: 'error', sessionSampleRate: 1 },
tags: { errorSampleRate: 0, sessionSampleRate: 1 },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also side note: I think eventually, we'll want to remove these tags as well, right? IMO they don't really add value for our users and SDKs shouldn't just add additional tags to events (unless there's a justified reason to do so ofc). That being said, I know that it's convenient for us to have this data so we might want to think about a similar approach for the sample rate tags. WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep I have a follow-up here: #6659

@billyvg billyvg merged commit 7408b0a into master Jan 6, 2023
@billyvg billyvg deleted the feat-replays-add-replay-type-to-event branch January 6, 2023 15:15
@lforst
Copy link
Contributor

lforst commented Jan 7, 2023

billyvg added a commit that referenced this pull request Jan 7, 2023
Fixes type error from #6658 (semantic merge issue).
@billyvg
Copy link
Member Author

billyvg commented Jan 7, 2023

@lforst ah thanks fixed in #6681

mydea pushed a commit that referenced this pull request Jan 9, 2023
Fixes type error from #6658 (semantic merge issue).
mydea pushed a commit that referenced this pull request Jan 9, 2023
Fixes type error from #6658 (semantic merge issue).
billyvg added a commit that referenced this pull request Jan 18, 2023
billyvg added a commit that referenced this pull request Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants