feat(core): Add client outcomes for breadcrumbs buffer #15082
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size-limit report 📦
|
AbhiPrasad
requested review from
mydea,
a team and
s1gr1d
and removed request for
a team
s1gr1d
reviewed
Jan 22, 2025
Comment on lines
+482
to
+486
| this._breadcrumbs.push(mergedBreadcrumb); | ||
| if (this._breadcrumbs.length > maxCrumbs) { | ||
| this._breadcrumbs = this._breadcrumbs.slice(-maxCrumbs); | ||
| this._client?.recordDroppedEvent('buffer_overflow', 'log_item'); | ||
| } |
There was a problem hiding this comment.
Do we even need to push the breadcrumb if the length is already overflowing? 🤔
Correct me if I understood it wrong.
Suggested change
| this._breadcrumbs.push(mergedBreadcrumb); | |
| if (this._breadcrumbs.length > maxCrumbs) { | |
| this._breadcrumbs = this._breadcrumbs.slice(-maxCrumbs); | |
| this._client?.recordDroppedEvent('buffer_overflow', 'log_item'); | |
| } | |
| if (this._breadcrumbs.length >= maxCrumbs) { | |
| this._client?.recordDroppedEvent('buffer_overflow', 'log_item'); | |
| } else { | |
| this._breadcrumbs.push(mergedBreadcrumb); | |
| } |
There was a problem hiding this comment.
I chose to keep the old behaviour of always pushing a breadcrumb, and conditionally calling truncating logic.
If we think about the buffer always trying to maintain max capacity, this makes the most sense. I don't think it's too much of a cost to keep the extra element in the buffer.
s1gr1d
approved these changes
Jan 23, 2025
AbhiPrasad
added a commit
that referenced
this pull request
Jan 23, 2025
ref getsentry/team-sdks#116 This PR implements a new client discard reason for `buffer_overflow`. This will be used to track when the internal breadcrumbs buffer overflows for the new logs product that we are working on. This is documented in develop here: getsentry/sentry-docs#12395 Note: The reason we have `buffer_overflow` as a separate item to `queue_overflow` is that in the future when we send log items in envelopes we'll increment `queue_overflow` for the transport queue. We want to differentiate between the transport queue and the internal buffer explicitly.
AbhiPrasad
added a commit
that referenced
this pull request
Jan 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ref getsentry/team-sdks#116
This PR implements a new client discard reason for
buffer_overflow. This will be used to track when the internal breadcrumbs buffer overflows for the new logs product that we are working on. This is documented in develop here: getsentry/sentry-docs#12395Note: The reason we have
buffer_overflowas a separate item toqueue_overflowis that in the future when we send log items in envelopes we'll incrementqueue_overflowfor the transport queue. We want to differentiate between the transport queue and the internal buffer explicitly.