Allow overriding sampling rate for events

[darrell-roberts]

Problem Statement

Most event capture will use the sampling rate for the client, however there are some events we consider high priority we want to always send. This would require a user defined function that allows use to set something on the event that we could check for by-passing the sampling rate.

Solution Brainstorm

Add a user defined function to ClientOptions that receives an event and checks if it qualifies for ignoring the configured sampling rate.
Have prepare_event check for user defined sampling override and check if sampling rate should be ignored.

[linear-code]

RUST-215

[darrell-roberts]

Created draft PR: #1128

[szokeasaurusrex]

Hi @darrell-roberts, thanks for the issue and the draft PR!

Rather than adding a function that returns a boolean to fully ignore the sample rate, I would suggest we instead add support for an error_sampler function, like we have in the Python SDK, which returns a floating-point value instead of a boolean. That version allows sampling different events at different sample rates, in addition to supporting your use case.

However, as adding fields to the ClientOptions is a breaking change, we will need to carefully consider if/when we should make this change.

[darrell-roberts]

Hi @darrell-roberts, thanks for the issue and the draft PR!

Rather than adding a function that returns a boolean to fully ignore the sample rate, I would suggest we instead add support for an error_sampler function, like we have in the Python SDK, which returns a floating-point value instead of a boolean. That version allows sampling different events at different sample rates, in addition to supporting your use case.

Hi @szokeasaurusrex

Thanks. The approach in the python SDK is a better approach. I've updated the draft PR with the suggestion.

However, as adding fields to the ClientOptions is a breaking change, we will need to carefully consider if/when we should make this change.

This may be ok, in the sense if no user defined sampling rate override function is provided it falls back to the default behavior.

[szokeasaurusrex]

This may be ok, in the sense if no user defined sampling rate override function is provided it falls back to the default behavior.

@darrell-roberts the problem is that the ClientOptions struct is a pub struct with all pub fields. Even though most users will likely construct ClientOptions by setting a few fields manually then having ..Default::default fill in the rest, it is still possible to exhaustively construct and/or to exhaustively match against the ClientOptions struct. As adding a field will break code which exhaustively constructs or matches the struct, it is a breaking change.

At some point, I would like to refractor ClientOptions so that we can add functionality in a non-breaking manner, but this itself will be a disruptive breaking change, as it would require fundamentally changing the API. So that will only happen after careful consideration.

[darrell-roberts]

This may be ok, in the sense if no user defined sampling rate override function is provided it falls back to the default behavior.

@darrell-roberts the problem is that the ClientOptions struct is a pub struct with all pub fields. Even though most users will likely construct ClientOptions by setting a few fields manually then having ..Default::default fill in the rest, it is still possible to exhaustively construct and/or to exhaustively match against the ClientOptions struct. As adding a field will break code which exhaustively constructs or matches the struct, it is a breaking change.

At some point, I would like to refractor ClientOptions so that we can add functionality in a non-breaking manner, but this itself will be a disruptive breaking change, as it would require fundamentally changing the API. So that will only happen after careful consideration.

What do you suggest I do with this issue / PR?

[szokeasaurusrex]

@darrell-roberts the issue can remain and on the backlog. I have applied a label to indicate that this would require a breaking change. Unless we see huge demand for this feature, we likely will not make a major release only to add this feature, but we can include it with the next major release, whenever that occurs. I do not have a specific timeline for the next major release, but likely within a few months.

I would ask that we close the PR for now, just to keep things tidy. We can revive the branch whenever we are ready to make the change.

[szokeasaurusrex]

Also, as a workaround until we release this change, you might be able to implement custom sampling logic in before_send.

Doing this would require you to set a sample_rate of 1.0 (the default), and then to implement your custom sampling logic in before_send. This setup could look something like the following pseudocode:

fn sample_rate(e: Event) -> f64 {
    todo!("implement custom sampling logic");
    // return value between 0.0 and 1.0 inclusive
}

sentry::init(("<dsn>", ClientOptions {
    sample_rate: 1.0,
    before_send: |event| (rand::rng().random() < sample_rate(event)).then_some(event),
    ..Default::default()
}