poc(sdk): Add experimental dsn for upcoming perf work #36000
Conversation
This adds an experimental dsn to the MultiplexingTransport to intentionally send specific flagged events solely to a separate dsn, which will help us avoid troubles with ingesting random errors into our main Sentry project.
github-actions
bot
added
the
Scope: Backend
| if is_current_event_experimental(): | ||
| if rate and random.random() < rate: | ||
| getattr(experimental_transport, method_name)(*args, **kwargs) | ||
| # Experimental events should not be sent to other transports even if they are not sampled. |
There was a problem hiding this comment.
I don't think you can do that. By setting the experimental flag on the scope you're effectively dropping the transaction for that web request. Or do you intend to push a new scope for producing the experimental event?
There was a problem hiding this comment.
It's pushing a new scope for capturing the exception and setting the tag there, so only the error event will be sent to the experimental dsn.
There was a problem hiding this comment.
There was a problem hiding this comment.
ok. if this scope leaks for some reason (concurrency bug of some sort) we're royally screwed.
may i suggest creating a completely separate SDK setup (not even using the same client)?
basic_client = Hub(Client(mydsn))
with basic_client:
capture_event(...)inside of the with-statement, you are using the new client and can send your events. the events are on a separate transport queue just as well
the scope is not the same, all request data will be missing from your events. but on the flipside this is much stronger isolation.
this is how pytest-sentry isolates things.
I am not sure if you can live with not having any other scope data though
There was a problem hiding this comment.
scope leaks for some reason
Like how the transports were leaking before? 😆
I don't really expect the scope to leak, do we have any active issues with scope leaking that would make this more of a concern? The failure case, (being screwed here, lol) would only happen flipping the rate switch for the experimental dsn, which we can immediately turn off, and just for SaaS events, I feel like a separate client might be a bit too defensive?
| @@ -309,6 +309,9 @@ | |||
| # Note: A value that is neither 0 nor 1 is regarded as 0 | |||
| register("store.use-relay-dsn-sample-rate", default=1) | |||
|
|
|||
| # A rate to apply to any events denoted as experimental to be sent to an experimental dsn. | |||
| register("store.use-experimental-dsn-sample-rate", default=0.0) | |||
There was a problem hiding this comment.
reminder, please pre-register this option in a separate PR and set it to 0 explicitly
k-fish
deleted the
poc/perf-py-sdk-add-experimental-sdk-options-and-transport
branch
Summary
This adds an experimental dsn/transport to the MultiplexingTransport to intentionally send specific flagged events solely to a separate dsn, which will help us avoid troubles with ingesting random errors into our main Sentry project.
Will be followed up with the perf-issue experimental sdk changes to be added to
getsentryalong with adding the experimental dsn key (experimental_dsn) there.Refs: getsentry/sentry-python@caa4140