feat(events): Detect oversized events and reduce their size #4903
Conversation
adinauer
requested review from
lcian,
markushi,
romtsn and
stefanosiano
as code owners
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Features
- Detect oversized events and reduce their size ([#4903](https://github.com/getsentry/sentry-java/pull/4903))If none of the above apply, you can opt out of this check by adding |
| * Callback invoked when an oversized event is detected. This allows custom handling of oversized | ||
| * events before the automatic reduction steps are applied. | ||
| */ | ||
| private @Nullable OnOversizedErrorCallback onOversizedError; |
There was a problem hiding this comment.
What should we best call this so customers know what it's used for?
Should this instead be more like an EventProcessor interface, where we can add methods for each feature (error events, spans, ...) in the future?
| private @Nullable OnOversizedErrorCallback onOversizedError; | |
| private @Nullable OnOversizedEventCallback onOversizedEvent; |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| reducedEvent = onOversizedError.execute(reducedEvent, hint); | ||
| if (!isTooLarge(reducedEvent, options)) { | ||
| return reducedEvent; | ||
| } |
There was a problem hiding this comment.
Bug: Misinterpreted Null Leads to Silent Data Loss
When onOversizedError callback returns null (violating its @NotNull contract), the code treats this as success because byteSizeOf(null) returns 0, making isTooLarge return false. This causes the event to be silently dropped without error logging, instead of continuing with automatic reduction. The callback result needs validation before the size check.
| if (!isTooLarge(reducedEvent, options)) { | ||
| return reducedEvent; | ||
| } | ||
| } catch (Exception e) { |
There was a problem hiding this comment.
Bug: Callback Errors: A Crash Hazard
The callback exception handler catches Exception instead of Throwable, inconsistent with other callback handlers in the codebase like executeBeforeSend. This means Error subclasses (like OutOfMemoryError) thrown by the callback won't be caught, potentially crashing the SDK instead of continuing with automatic reduction.
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| ee747ae | 415.92 ms | 470.15 ms | 54.23 ms |
| 9fbb112 | 401.87 ms | 515.87 ms | 114.00 ms |
| 9fbb112 | 404.51 ms | 475.65 ms | 71.14 ms |
| 604a261 | 380.65 ms | 451.27 ms | 70.62 ms |
| 674d437 | 355.28 ms | 504.18 ms | 148.90 ms |
| 33a08cc | 267.08 ms | 340.45 ms | 73.37 ms |
| 27d7cf8 | 309.43 ms | 364.27 ms | 54.85 ms |
| 96449e8 | 361.30 ms | 423.39 ms | 62.09 ms |
| c8125f3 | 397.65 ms | 485.14 ms | 87.49 ms |
| ee747ae | 382.73 ms | 435.41 ms | 52.68 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| ee747ae | 1.58 MiB | 2.10 MiB | 530.95 KiB |
| 9fbb112 | 1.58 MiB | 2.11 MiB | 539.18 KiB |
| 9fbb112 | 1.58 MiB | 2.11 MiB | 539.18 KiB |
| 604a261 | 1.58 MiB | 2.10 MiB | 533.42 KiB |
| 674d437 | 1.58 MiB | 2.10 MiB | 530.94 KiB |
| 33a08cc | 1.58 MiB | 2.12 MiB | 555.28 KiB |
| 27d7cf8 | 1.58 MiB | 2.12 MiB | 549.42 KiB |
| 96449e8 | 1.58 MiB | 2.11 MiB | 539.35 KiB |
| c8125f3 | 1.58 MiB | 2.10 MiB | 532.32 KiB |
| ee747ae | 1.58 MiB | 2.10 MiB | 530.95 KiB |
| * Enables event size limiting with {@link EventSizeLimitingEventProcessor}. When enabled, events | ||
| * exceeding 1MB will have breadcrumbs and stack frames reduced to stay under the limit. | ||
| */ | ||
| private boolean enableEventSizeLimiting = false; |
There was a problem hiding this comment.
Kepping this opt-in for now, we could turn it on by default in the next major.
| * @return the modified event (should ideally be reduced in size) | ||
| */ | ||
| @NotNull | ||
| SentryEvent execute(@NotNull SentryEvent event, @NotNull Hint hint); |
There was a problem hiding this comment.
IMO running this between beforeSend and passing this on to the transport is the best place to check since customers might be adding large amounts of data in beforeSend, so first reducing size and then adding back to it could easily cause the event to become too large again.
📜 Description
Detect oversized events and reduce their size by removing breadcrumbs and reducing stack trace size.
Also add
onOversizedErrorcallback that allows customers to customize what's dropped.💡 Motivation and Context
So we can be more lenient with truncation in SDK and only perform it if required to reduce event size.
💚 How did you test it?
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps