You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix(clientreport): Stop deserializing discarded logs (JAVA-662)
ClientReportRecorder counted discarded log and metric items by fully
deserializing the envelope payload just to read its size. On the discard
path this runs continuously under sustained rate limiting, and the JSON
reader's error-tolerant recovery throws an exception per token, pinning
CPU cores in a busy-loop (fillInStackTrace dominated the profile).
The item count is already stored in the envelope item header, so read it
from there instead of deserializing. Byte counts still come from the raw
data. This makes the discard path O(1) and allocation/exception-free.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* changelog
* test(clientreport): Cover both onDiscard restore entry points (JAVA-662)
The two tests asserting that restoring counts from an attached client
report does not re-fire onDiscard were named for their setup rather than
for what actually differed between them, which made the pair read as an
accidental duplicate.
Name each for its entry point and share the setup and verifications, so
it is clear the property is being pinned for both recordLostEnvelope and
recordLostEnvelopeItem.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,11 @@
2
2
3
3
## Unreleased
4
4
5
+
### Fixes
6
+
7
+
- Avoid a CPU busy-loop when recording discarded log or metric envelopes under rate limiting ([#5835](https://github.com/getsentry/sentry-java/pull/5835))
8
+
- `ClientReportRecorder` now reads the item count from the envelope item header instead of deserializing the payload, which under sustained rate limiting could pin CPU cores while repeatedly throwing exceptions
9
+
5
10
### Performance
6
11
7
12
- Remove an unused lock from `SentryPerformanceProvider`, which was allocated on every cold start in `ContentProvider.onCreate` without ever being acquired ([#5871](https://github.com/getsentry/sentry-java/pull/5871))
0 commit comments