Repository navigation
Conversation
size-limit report 📦
|
|
bugbot review |
e92e60e to
d85d55a
Compare
span client report outcomes if span streaming is disabledspan client report outcomes also when span streaming is disabled
| client.recordDroppedEvent('sample_rate', 'span'); | ||
|
|
There was a problem hiding this comment.
this is now handled via startSpan APIs
f6935b4 to
514d50a
Compare
932a210 to
b2c14c7
Compare
b2c14c7 to
e80b42f
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e80b42f. Configure here.
span client report outcomes also when span streaming is disabledspan client report outcomes when discarding transactions
|
👋 @chargome — Please review this PR when you get a chance! |
…d failures (#25185) When sending an envelope fails (network error, 413, or a full buffer), the transport recorded every item with quantity 1. This undercounts span, log and metric discard quantities. Same for transactions that [should also](https://develop.sentry.dev/sdk/telemetry/client-reports/#span-outcomes) report `span` counts. Containers now report their `item_count`, and transactions also report `spans.length + 1` `span` outcomes, matching how the client counts dropped transactions in `beforeSend`. For transactions, we also record `span` outcomes on envelope send failures, analogously to what #25006 adds to other discard reasons --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
e80b42f to
b54716b
Compare
chargome
left a comment
There was a problem hiding this comment.
Nice change, thanks for the correction on transactions! I think some browser tests might still need an update but otherwise LGTM
| dynamicSamplingContext?: Partial<DynamicSamplingContext>; | ||
| capturedSpanScope?: Scope; | ||
| capturedSpanIsolationScope?: Scope; | ||
| spanCountBeforeProcessing?: number; |
There was a problem hiding this comment.
If this exported this is theoretically breaking, but I guess fine as we should be only using this internally
There was a problem hiding this comment.
Good point, I missed this, thanks! While I think removing it would probably be fine, given this is internal metadata, it also doesn't cost us anything to keep it around and mark it as deprecated. We can remove it in v12.
An unsampled standalone span (e.g. a late INP span) recorded a `transaction` outcome when it started, although it never becomes a transaction, and a second `span` outcome when it ended. Record a single `span` outcome on start instead. Derive the expected span count in the static sampling integration test from the `GET /ok` transaction, so it also holds on Bun, which creates no Express spans. Co-Authored-By: Claude <noreply@anthropic.com>
Run event processors, `ignoreSpans`, `beforeSendSpan` and `beforeSendTransaction` on the same transaction and check that every span is either sent or counted exactly once, both when the transaction is sent and when `beforeSendTransaction` drops it. Co-Authored-By: Claude <noreply@anthropic.com>
…ceholder span When `onlyIfParent` finds no parent, the non-recording placeholder span becomes active. Spans started inside it were recorded as `sample_rate` drops (and since span outcomes are now recorded on the static path, also without span streaming). Give the placeholder a `no_parent_span` drop reason so nested spans inherit it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…s` on the static path Without span streaming, `ignoreSpans` is applied to the transaction event in `processBeforeSend`. Spans and transactions dropped there were recorded as `before_send`, while span streaming records `ignored` for the same drop. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…not be sent Unsampled spans record their outcome when they start, so spans a sampled transaction would never contain (e.g. unfinished children) are counted too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
b54716b to
db09aac
Compare
…ent reports Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ingMetadata` Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The client report spec calls for recording category
spanclient outcomes, also if streaming is disabled. This PR makes the change to record outcomes for each span, including one for the transaction itself when a transaction is sampled negatively, as well as when it's dropped.The transaction/event processing pipeline had a bunch of holes for discarded span counts, since any combination of
ignoreSpans, event processors andbeforeSendTransactioncould drop child spans in any of those callbacks. So for example, a transaction that originally had 10 child spans and dropsnow all together reports 11
spans and 1transactionoutcome, with the correct reasons. No span drops are double-counted.Related bugfix: Spans dropped by
ignoreSpanswithout span streaming are now recorded asignoredinstead ofbefore_send.