-
Notifications
You must be signed in to change notification settings - Fork 526
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
feat(tracing): Backfill missing sample_rand
on PropagationContext
#4038
Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #4038 +/- ##
==========================================
+ Coverage 79.55% 79.59% +0.03%
==========================================
Files 140 140
Lines 15523 15581 +58
Branches 2631 2643 +12
==========================================
+ Hits 12349 12401 +52
- Misses 2338 2343 +5
- Partials 836 837 +1
|
14a70da
to
0a0de06
Compare
PropagationContext
has sample_rand
sample_rand
on PropagationContext
21bb038
to
836d5b1
Compare
836d5b1
to
cbfc36a
Compare
cbfc36a
to
6f66ce8
Compare
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.
left some initial comments,
- the new computation
_sample_rand_transformation
and corresponding tests look fine - for the lifecycle of which cases
_fill_sample_rand
might behave weirdly, I need to think a bit more
Apart from that, this PR is touching mainly the TwP use case so please do some manual testing of TwP cases in a distributed setup (JS frontend + Python backend) and post trace links / screenshots.
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.
Please see my responses. Going to work on implementing requested changes now
fec92c5
to
d486a8f
Compare
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.
Left two more suggestions. Please review. (And also please make sure Neel is also ok with the PR before merging)
382ef64
to
beb943b
Compare
this looks fine now, we will first review the other PRs, merge and test before merging this into master, so I'm making this a draft for now. |
5ffab05
to
cb8e728
Compare
@sentrivana I have implemented the fixed-precision in this PR. Please re-review. Still need to do manual testing (will do this against the final PR in this stack) |
cb8e728
to
9863506
Compare
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.
Left some comments. I'm also not sure if the Decimal stuff is an improvement; with floats the code read much easier as we didn't have to do all the conversions (float -> decimal, decimal -> int, int -> decimal, decimal -> float again)...
sentry_sdk/tracing_utils.py
Outdated
DECIMAL_0 = Decimal(0) | ||
DECIMAL_1 = Decimal(1) |
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.
What is the purpose of these aliases?
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.
To appease the linter – these values are used in the default parameter value for the generate
method. The linter complains because the values are generated once per program run, which is fine, since Decimal
values are immutable. To indicate that this is intentional, we need to set them as constants (or I suppose, we could disable the lint on that line).
sentry_sdk/tracing_utils.py
Outdated
if lower_int == upper_int: | ||
# Edge case: lower_decimal < upper_decimal, but due to rounding, | ||
# lower_int == upper_int. In this case, we return | ||
# lower_int.scaleb(-SCALE_EXPONENT) here, since calling randrange() | ||
# with the same lower and upper bounds will raise an error. |
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.
How exactly can this happen? You write due to rounding
, but we're only working with decimals/integers here?
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.
Consider the case where lower_decimal = Decimal("0.500_000_0")
and upper_decimal = Decimal("0.500_000_9")
.
In this case, lower_int
and upper_int
will both be equal to 500_000
, since the seventh digit after the decimal is truncated by int
.
I would at least keep the random generation as integer ranges, that way we have precise control to ensure the upper bound is excluded from the range. Not sure about the |
c60cb71
to
2b3f4f7
Compare
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.
thanks! 👍🏻
Whenever the `PropagationContext` continues an incoming trace (i.e. whenever the `trace_id` is set, rather than being randomly generated as for a new trace), check if the `sample_rand` is present and valid in the incoming DSC. If the `sample_rand` is missing, generate it deterministically based on the `trace_id` and backfill it into the DSC on the `PropagationContext`. When generating the backfilled `sample_rand`, we ensure the generated value is consistent with the incoming trace's sampling decision and sample rate, if both of these are present. Otherwise, we generate a new value in the range [0, 1). Future PRs will address propagating the `sample_rand` to transactions generated with `continue_trace` (allowing the `sample_rand` to be propagated on outgoing traces), and will also allow `sample_rand` to be used for making sampling decisions. Ref #3998
2b3f4f7
to
789b065
Compare
Dismissing this review, since all of the requested changes have been made, and Neel is on vacation, so he cannot approve the PR until he is back.
Use the `sample_rand` value from an incoming trace to make sampling decisions, rather than generating a random value. When we are the head SDK starting a new trace, save our randomly-generated value as the `sample_rand`, and also change the random generation logic so that the `sample_rand` is computed deterministically based on the `trace_id`. Depends on: - #4040 - #4038 Closes #3998
`continue_trace` now propagates incoming `sample_rand` values to the transaction's baggage. Also, in the case where `sample_rand` is missing from the incoming trace and needs to be backfilled, this change introduces a mechanism for the backfilled value from the scope's propagation context to be propagated to the transaction's baggage. The transaction still does not use the `sample_rand` for making sampling decisions; this PR only enables propagation. A future PR will add support for reading the incoming/backfilled `sample_rand` and for using this value to make sampling decisions. Depends on: - #4038 Ref #3998
Whenever the
PropagationContext
continues an incoming trace (i.e. whenever thetrace_id
is set, rather than being randomly generated as for a new trace), check if thesample_rand
is present and valid in the incoming DSC. If thesample_rand
is missing, generate it deterministically based on thetrace_id
and backfill it into the DSC on thePropagationContext
.When generating the backfilled
sample_rand
, we ensure the generated value is consistent with the incoming trace's sampling decision and sample rate, if both of these are present. Otherwise, we generate a new value in the range [0, 1).Future PRs will address propagating the
sample_rand
to transactions generated withcontinue_trace
(allowing thesample_rand
to be propagated on outgoing traces), and will also allowsample_rand
to be used for making sampling decisions.Ref #3998