Breadcrumb eviction in Scope.addBreadcrumb is reported as a discarded log_item (buffer_overflow)

Bắt đầu trong packages/core/src/scope.ts tại Scope.addBreadcrumb và kiểm tra cách eviction gọi recordDroppedEvent. Tái hiện trường hợp có nhiều hơn maxBreadcrumbs entry, sau đó xác minh rằng việc eviction breadcrumb không còn xuất hiện dưới dạng buffer_overflow/log_item, sử dụng các test hiện có của repository cho hành vi của scope nếu có.

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.73.0

Framework Version

Next 16.3.4

Link to Sentry event

No response

Reproduction Example/SDK Setup

Any app that adds more than maxBreadcrumbs (default 100) breadcrumbs to a scope.

Steps to Reproduce

1. Keep a scope alive long enough to add 101 breadcrumbs (a long-lived server scope, or a browser page with console/fetch/click breadcrumbs).
2. Look at the client reports the SDK sends, or at Sentry → Stats → Outcomes for the project.

Expected Result

Breadcrumb eviction from the ring buffer is not a discarded log item. Either it is not reported as a client report at all (a breadcrumb is context, and 100 is the intended cap), or it is reported under a breadcrumb-shaped reason/category rather than log_item.

Actual Result

Scope.addBreadcrumb records a client report with reason buffer_overflow and category log_item every time the breadcrumb buffer evicts an entry:

// packages/core/src/scope.ts (develop), same in @sentry/core 10.73.0 build/cjs/scope.js:394
this._breadcrumbs.push(mergedBreadcrumb);
if (this._breadcrumbs.length > maxCrumbs) {
  this._breadcrumbs = this._breadcrumbs.slice(-maxCrumbs);
  this._client?.recordDroppedEvent('buffer_overflow', 'log_item');
}

In Sentry's Stats page this shows up as discarded log items, client_discard · buffer_overflow, and in our project it dwarfs accepted logs: 84,981,094 "discarded" against 1,692,344 accepted log items over 7 days. We spent an investigation working out that none of those were log lines: the logs buffer flushes at 100 items / 800 KB / 5 s and never discards for this reason, so the only source of buffer_overflow · log_item in the SDK is breadcrumb eviction. The mislabel makes the Stats page read as if 98% of logs are lost in-process, when nothing is.

Suggested fix: drop the recordDroppedEvent call in addBreadcrumb, or give it its own reason/category so it cannot be read as log loss.