-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(sampling): Remove stray sampling data tags #3197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
transactionSampling: { | ||
method: TransactionSamplingMethod.Sampler, | ||
// cast to number in case it's a boolean | ||
rate: Number(sampleRate), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jan-auer Once consequence of this change is that rates will come through as numbers rather than strings. (When I did the original PR, tags had to be strings, which is why I stringified the value in the first place.) LMK if that's not good from a relay perspective and I can turn them back into strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this what you put into the sample_rates
item header? The schema in there is:
type SampleRate = {
id: String,
rate: Number,
}
If this goes into the header, let's rather keep it consistent to avoid mistakes please. As for the rate, that should be a number all along.
size-limit report
|
@@ -3,6 +3,7 @@ | |||
**/ | |||
export interface DebugMeta { | |||
images?: Array<DebugImage>; | |||
transactionSampling?: { rate?: number; method?: string }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we call it rate
and id
in the protocol, couldn't we unify it here as well? It'd make some object deconstruction easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make object deconstruction easier. I didn't do it because id
is opaque. What's it the id of? Unless you feel strongly I'd rather keep it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree, but why is Relay using it in the first place? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll have to take that up with @jan-auer 😛
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See also #3197 (comment). Relay doesn't use this field, but it also sample in its own way. The id
field identifies not only the method but in case of Relay also the rule which applied.
Ultimately, this all ends up in Sentry and in our data pipeline.
75ee7af
to
ab8e93b
Compare
ab8e93b
to
c69a371
Compare
Follow up to #3068.
In that PR, tags were used as a temporary way to get data through the event processors to the point where envelope headers are created. Once used, they were deleted from
event.tags
. Unfortunately, by that point they'd already been copied intocontexts.trace
, from which they weren't being deleted, causing them to show up in the UI.This PR fixes that by using
debug_meta
instead oftags
(which means that even if something goes wrong, it's only visible in the event JSON, not the UI) and adds a test to ensure that the data isn't where it shouldn't be. (It also does some cleanup work in that test suite to simplify things.)