fix(core): [Callback Errors 2] Drop failed processor data

[adinauer]

PR Stack (Callback Errors)

• fix(core): Handle callback errors #6140
• fix(core): [Callback Errors 1] Report callback failures #6141
• fix(core): [Callback Errors 2] Drop failed processor data #6142
• fix(core): [Callback Errors 3] Drop failed breadcrumbs #6143

---

📜 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.

• refs: Align callback error handling with other SDKs #6081

💚 How did you test it?

• ./gradlew spotlessApply apiDump
• ./gradlew :sentry:test --tests io.sentry.SentryClientTest

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

The final stack PR changes beforeBreadcrumb exception handling.

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please 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.

Generated by 🚫 dangerJS against d689526

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.57.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[sentry]

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}

Suggested Fix

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 Agent

Review 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.}