fix(core): [Callback Errors 2] Drop failed processor data - #6142
adinauer wants to merge 1 commit into
Conversation
Sorry, something went wrong.
Stop processing and drop telemetry when an event processor throws. Record callback_error outcomes for every supported category instead of sending potentially partially processed data. Refs #6081 Co-Authored-By: Claude <noreply@anthropic.com>
Instructions and example for changelogPlease add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number. Example: ## Unreleased
### Fixes
- [Callback Errors 2] Drop failed processor data ([#6142](https://github.com/getsentry/sentry-java/pull/6142))If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label. |
Sorry, something went wrong.
📲 Install BuildsAndroid
|
Sorry, something went wrong.
| e, | ||
| "An exception occurred while processing replay event by processor: %s", | ||
| processor.getClass().getName()); | ||
| options | ||
| .getClientReportRecorder() | ||
| .recordLostEvent(DiscardReason.CALLBACK_ERROR, DataCategory.Replay); | ||
| return null; | ||
| } | ||
|
|
||
| if (replayEvent == null) { |
There was a problem hiding this comment.
Bug: If an EventProcessor mutates an event and then throws, the client report will incorrectly record the byte size of the mutated event, not the original.
Severity: MEDIUM
Calculate the byte size of the event before calling the processor, rather than after catching an exception. Alternatively, create a defensive copy of the event object before passing it to the processor if the object supports cloning.
Prompt for AI AgentReview the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: sentry/src/main/java/io/sentry/SentryClient.java#L691-L700 Potential issue: In `processLogEvent` and `processMetricsEvent`, a reference to the event is stored in `eventBeforeProcessor` before it is passed to an `EventProcessor`. If the processor mutates the event in-place and then throws an exception, the subsequent call to `recordLostLogEvent` or `recordLostMetricsEvent` will calculate the byte size based on the mutated event, not the original one. This leads to inaccurate byte counts being recorded in client reports for dropped events, as the `EventProcessor` interface explicitly allows for in-place mutation.
Also affects:
- sentry/src/main/java/io/sentry/SentryClient.java:729~738
Did we get this right? 👍 / 👎 to inform future reviews.
Sorry, something went wrong.
PR Stack (Callback Errors)
📜 Description
Drops the current telemetry item when an EventProcessor throws. Subsequent processors and beforeSend* callbacks do not run, and the item is not sent or added to a batch.
Processor exceptions record callback_error outcomes for errors, transactions and spans, replays, feedback, logs and log bytes, and metrics and metric bytes. Intentional processor null results continue to use event_processor.
💡 Motivation and Context
Continuing after a processor failure can send partially processed data, including data that a customer processor intended to scrub. Failing closed keeps callback failures isolated from the host while preventing unsafe delivery.
💚 How did you test it?
📝 Checklist
🔮 Next steps
The final stack PR changes beforeBreadcrumb exception handling.