Repository navigation
Conversation
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 <[email protected]>
Contributor
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Fixes
- [Callback Errors 3] 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 |
This was referenced Sep 22, 2026
📲 Install BuildsAndroid
|
adinauer
marked this pull request as ready for review
September 23, 2026 08:50
adinauer
requested review from
0xadam-brown,
markushi,
romtsn and
runningcode
as code owners
September 23, 2026 08:50
4 of 9 tasks
adinauer
changed the base branch from
fix/callback-error-handling-discard-reason
to
fix/callback-error-handling-processor-marker
September 24, 2026 12:49
Make the preceding marker PR available to the processor failure policy. Preserve the existing stack commits and leave failure behavior unchanged. Co-Authored-By: Claude <[email protected]>
Use the internal processor marker to continue processing after SDK-owned processor failures without recording callback_error losses. Keep customer processor failures fail-closed across events, transactions, replays, feedback, logs, and metrics. Cover scope and options registration, continued callbacks and delivery, logging without discard notifications, intentional drops, and span loss accounting. Clarify the customer-only failure policy in the changelog. Refs #6081 Co-Authored-By: Claude <[email protected]>
This was referenced Sep 24, 2026
romtsn
approved these changes
Oct 5, 2026
romtsn
approved these changes
Oct 5, 2026
Propagate the latest main and preceding callback error changes through the stacked pull request. Co-Authored-By: Claude <[email protected]>
Base automatically changed from
fix/callback-error-handling-processor-marker
to
fix/callback-error-handling
October 8, 2026 10:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Stack (Callback Errors)
📜 Description
Drops the current telemetry item when a customer
EventProcessorthrows. Subsequent processors andbeforeSend*callbacks do not run, and the item is not sent or added to a batch.SDK-owned processors are identified by the internal
SentryEventProcessormarker from #6162. Their exceptions are logged, but processing continues with the current item, including subsequent processors andbeforeSend*callbacks. Nocallback_errorclient-report outcome orOnDiscardCallbacknotification is emitted for an SDK processor failure because the item is not dropped.Customer processor exceptions record
callback_erroroutcomes for errors, transactions and spans, replays, feedback, logs and log bytes, and metrics and metric bytes. Intentional processornullresults continue to useevent_processor, including for SDK-owned processors. Existing accounting for spans actually removed by a processor is preserved.The distinction applies regardless of registration through options or scope. Replay processors only run from options. The marker identifies the implementation hierarchy; customer subclasses of SDK processors inherit the marker.
💡 Motivation and Context
Continuing after a customer processor failure can send partially processed data, including data that the processor intended to scrub. Fail closed for customer code while preserving the existing continue-on-error behavior for SDK-owned processors. Client reports represent discarded telemetry, not internal exceptions that do not cause a drop.
💚 How did you test it?
./gradlew spotlessApply apiDump./gradlew :sentry:test --tests io.sentry.SentryClientTest --tests io.sentry.SentryClientInternalEventProcessorTest --tests io.sentry.ScopeTest --tests io.sentry.ScopesTest --tests io.sentry.clientreport.ClientReportTest --tests io.sentry.internal.eventprocessor.SentryEventProcessorTest :sentry:apiCheck :sentry:spotlessCheck— 588 tests passednullstill drop intentionally, and actual span removals retain their accounting. Before the SDK-specific guards, 15 new regression cases failed; all pass with the change.📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
The final stack PR changes
beforeBreadcrumbexception handling. Profile/replay artifact cleanup and profile discard accounting remain separate follow-ups; this update only distinguishes SDK-owned and customer processors. Existing catch types are unchanged.