-
Notifications
You must be signed in to change notification settings - Fork 484
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): Record lost spans in client reports #3244
Conversation
Marked as draft, still need to test this |
We need to keep track of the amount of spans prior |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## szokeasaurusrex/use-capture_record_lost_event_calls-fixture #3244 +/- ##
===============================================================================================
+ Coverage 79.35% 79.38% +0.03%
===============================================================================================
Files 132 132
Lines 14227 14243 +16
Branches 2987 2991 +4
===============================================================================================
+ Hits 11290 11307 +17
+ Misses 2092 2091 -1
Partials 845 845
|
@cleptric, does this mean that we also need to report dropped spans in the For example, in the situation below, do we report any dropped spans to Sentry? ![]() And for clarity, in the following situation where the transaction gets dropped after ![]() |
The first example reports two dropped spans, the second example reports six dropped spans and one dropped transaction. |
f098e6a
to
854b46c
Compare
1cc0144
to
0ce0523
Compare
cc4291c
to
3c62d91
Compare
sentry_sdk/tracing.py
Outdated
@@ -856,7 +854,8 @@ def finish(self, hub=None, end_timestamp=None): | |||
else: | |||
reason = "sample_rate" | |||
|
|||
client.transport.record_lost_event(reason, data_category="transaction") | |||
# No spans are discarded here because they were never recorded in the first place | |||
client.transport.record_lost_transaction(reason, span_count=0) |
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.
Just realized I still need to test this codepath
3c62d91
to
7a142ef
Compare
854b46c
to
9b6a718
Compare
`capture_record_lost_event_calls` replaces the `capture_client_reports` fixture. The fixture records calls to `Transport.record_lost_event` by noting the arguments passed to each call. This change is being introduced in preparation for #3244, which changes `Transport.record_lost_event`'s signature and behavior.
7a142ef
to
4c8dfff
Compare
Make the `report["discarded_events"]` assertion logic (in `test_data_category_limits_reporting`) not rely on the ordering of events or any sorting logic. Done in preparation of #3244, where the sorting logic cannot be relied on anymore, since the same number of spans will be discarded as transactions.
4c8dfff
to
fb4822a
Compare
…calls` Replace custom `record_lost_event` call capturing logic in `test_sampling.py` with the `capture_record_lost_event_calls` Pytest fixture. This change will simplify implementation of #3244.
07d9da7
to
f33be4a
Compare
b98f150
to
f8d866f
Compare
Also, update existing transport tests so they pass against the changes introduced in this commit. Resolves #3229
- Add test for `record_lost_event` method's new `quantity` parameter - Add test for `record_lost_event` when passed a transaction item
f8d866f
to
79e8970
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.
Very nice!
Resolves #3229
Resolves #3248
Note to reviewers: I have attempted to split the commits up into logical units, so you may wish to review the changes commit-by-commit.