sampleRate for error events silently prevents crash-free session marking

[lukapozega]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/vue

SDK Version

10.65.0

Framework Version

Vue 3.5.12

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

1. Sentry.init({ sampleRate: 0.01, ... })
2. Throw an unhandled error on every session.

Expected Result

Crash-free session rate should be 0%

Actual Result

With sample rate set to 0.01 Crash-free session rate stays ~99–100% because ~99% of the time, the error is dropped by sampleRate before the session is ever marked crashed.

Additional Context

In Client._processEvent():

• The sampleRate roll happens first and returns early on drop:
  https://github.com/getsentry/sentry-javascript/blob/develop/packages/core/src/client.ts#L1446

• Session status is only updated further down the same promise chain, so it's unreachable for anything dropped above:
  https://github.com/getsentry/sentry-javascript/blob/develop/packages/core/src/client.ts#L1484-L1487

beforeSend returning null has the exact same effect, for the same reason (it also short-circuits before reaching _updateSessionFromEvent).

This is different to what docs say:
Please note that the number of crashes is not expected to match the number of crashed sessions because sessions are not subject to [inbound filters](https://docs.sentry.io/concepts/data-management/filtering/) or [sampling](https://docs.sentry.io/platform-redirect/?next=/configuration/sampling/).

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-3156

[danielsheccoury-sentry]

Ticket link to the issue https://app.intercom.com/a/inbox/onh0p2wm/inbox/admin/10968572/conversation/215475213552169?view=Table

[s1gr1d]

Hello, and thanks for writing in!

I created a PR to fix this: #22671
This will also be backported to v10 (our working branch is already on v11).