feat(callbacks): [Callback Errors Optional Addon] Add opt-in strict callback mode

[adinauer]

PR Stack (Callback Errors)

• fix(core): Handle callback errors #6140
• fix(core): [Callback Errors 1] Report callback failures #6141
• ref(core): [Callback Errors 2] Mark SDK-owned event processors #6162
• fix(core): [Callback Errors 3] Drop failed processor data #6142
• fix(core): [Callback Errors 4] Drop failed breadcrumbs #6143
• fix(core): [Callback Errors 5] Handle tracesSampler failures #6163
• fix(core): [Callback Errors 6] Handle profilesSampler failures #6164
• fix(core): [Callback Errors 7] Handle replay sampling failures #6165
• fix(core): [Callback Errors 8] Report dropped profiles #6166
• fix(integrations): [Callback Errors 9] Guard custom callbacks #6167
• fix(callbacks): [Callback Errors 10] Handle nonfatal throwables #6251
• feat(callbacks): [Callback Errors Optional Addon] Add opt-in strict callback mode #6173

---

📜 Description

Add opt-in strictCallbackMode, disabled by default, so user callback failures propagate instead of being isolated by the SDK.

• Preserve exceptions and errors as distinct callback markers with the original failure as their cause.
• Centralize marker propagation in ExceptionUtils.maybeRethrow() before logging or discard accounting, including enclosing SDK catches and async completion paths. Leave the broader fatal-error policy unchanged.
• Silently exclude events containing callback markers, including nested/cyclic causes and ExceptionMechanismException, before capture callbacks, processors, logging, or discard accounting. Apply the same exclusion at JUL, Logback, Log4j2, and Timber entry points.
• Support SDK options, strict-callback-mode external configuration, io.sentry.strict-callback-mode Android metadata, and sentry.strict-callback-mode Spring Boot binding.

Async failures follow the host API's normal behavior: returned futures/completion stages retain the failure; the SDK does not forcibly terminate the process.

💡 Motivation and Context

Offer explicit callback-failure propagation without changing default behavior. Exclude the callback-failure event rather than bypassing the failed filter: sending it without customer filtering could expose sensitive data or re-enter the failing callback.

• refs: Align callback error handling with other SDKs #6081
• Spec discussion: docs(sdk): Specify callback error isolation for user callbacks sentry-docs#19189

This PR builds only on #6167; review its diff against fix/callback-error-handling-custom-callbacks, not main.

💚 How did you test it?

• 4,831 tests passed across core and affected integration/configuration suites, including default-off behavior, callback-marker propagation, cyclic/nested causes, capture exclusion, cleanup, and Spring/Android configuration.
• Four rebuilt console-sample probes covered exception/error markers both directly and nested in CompletionException: exit code 1, one callback invocation, zero discards, and zero HTTP requests.
• ./gradlew spotlessApply apiDump, apiCheck, and spotlessCheck passed.

📝 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

Address remaining SDK team review feedback on marker logging during uncaught-exception capture, feedback dismiss-listener cleanup, and proxy-only Log4j2 events. Broader fatal-error propagation remains deferred to the next major.

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

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 598c1dd

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[romtsn]

my clanker found a couple of perf optimizations here:

isCallbackException runs on every captureEvent / captureException and allocates an IdentityHashMap per call, even though markers can only exist when strictCallbackMode is on.

Two cheap fixes: short-circuit on options.isStrictCallbackMode() before walking, and replace the visited set with a depth bound like findRootCause does. The second one also matters for maybeRethrow, which runs inside catch blocks where allocating during an OOM is unsafe.

[romtsn]

Some things to address with this one