Skip to content

Conversation

@harshit078
Copy link

@harshit078 harshit078 commented Jan 13, 2026

This PR distinguishes replays that get dropped due to session length vs. transport/ratelimit reasons in the client report.

depends on #18901
closes #18316

@harshit078 harshit078 marked this pull request as ready for review January 13, 2026 20:34
@harshit078 harshit078 requested a review from a team as a code owner January 13, 2026 20:34
@chargome chargome self-assigned this Jan 19, 2026
Copy link
Member

@chargome chargome left a comment

Choose a reason for hiding this comment

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

Hey @harshit078 thanks for contributing! For the lack of better options in the drop reasons (see https://develop.sentry.dev/sdk/telemetry/client-reports/#envelope-item-payload) I think the most fitting is still send_error in this case.

if (err instanceof RateLimitError) {
dropReason = 'ratelimit_backoff';
} else if (err instanceof ReplayDurationLimitError) {
dropReason = 'sample_rate';
Copy link
Member

Choose a reason for hiding this comment

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

'sample_rate' would not be the correct drop reason here (this is only used in case an event was dropped because of the configured sample rate).

Copy link
Author

Choose a reason for hiding this comment

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

got it then if im not wrong then is network_error the appropriate drop reason ?

Copy link
Member

@chargome chargome Jan 19, 2026

Choose a reason for hiding this comment

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

No, let's work with ignored for now (We might add a new drop reason in the future!) – please also update the browser integration tests for this

Copy link
Author

Choose a reason for hiding this comment

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

Make sense, I'll update it

Copy link
Member

Choose a reason for hiding this comment

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

@harshit078 actually we'll introduce a new reason right away so this stays consistant. Mind if I take this PR over? The rest looks good already

Copy link
Author

Choose a reason for hiding this comment

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

sure please go ahead

cursor[bot]

This comment was marked as outdated.

@chargome chargome changed the title feat(replay): Introduce ReplayDurationLimitError and enhance error ha… feat(replay): Update client report discard reason for invalid sessions Jan 20, 2026
@chargome chargome marked this pull request as draft January 20, 2026 15:38
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

dropReason = 'invalid';
} else {
dropReason = 'send_error';
}
Copy link

Choose a reason for hiding this comment

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

Invalid drop reason not in EventDropReason type

Medium Severity

The drop reason 'invalid' is used when recording a dropped event for ReplayDurationLimitError, but 'invalid' is not a valid value in the EventDropReason type defined in packages/core/src/types-hoist/clientreport.ts. The valid reasons are: 'before_send', 'event_processor', 'network_error', 'queue_overflow', 'ratelimit_backoff', 'sample_rate', 'send_error', 'internal_sdk_error', 'buffer_overflow', and 'ignored'. The PR discussion mentioned using 'ignored' initially, suggesting this may be an oversight where either 'ignored' should be used, or 'invalid' needs to be added to the EventDropReason type.

Fix in Cursor Fix in Web

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.

Inaccurate outcome when flushing replays

2 participants