Skip to content

fix(spring): Handle transaction name provider failures - #6241

Draft
adinauer wants to merge 3 commits into
fix/callback-error-handlingfrom
fix/callback-error-handling-spring-transaction-name-provider
Draft

adinauer wants to merge 3 commits into
fix/callback-error-handlingfrom
fix/callback-error-handling-spring-transaction-name-provider

Conversation

@adinauer

@adinauer adinauer commented Oct 9, 2026

Copy link
Copy Markdown
Member

📜 Description

Handle exceptions from Spring TransactionNameProvider callbacks across event capture, request processing, tracing, and combined providers. Nonfatal failures use <unlabeled transaction> with a custom source, while fatal JVM errors continue to propagate.

Combined providers continue trying later providers after a failure. If none succeeds, they use the safe fallback; ordinary unresolved providers still preserve the existing null result.

The implementation is mirrored across Spring, Spring Jakarta, and Spring 7.

💡 Motivation and Context

A custom transaction-name provider can currently interrupt request processing or event capture. Returning a fixed fallback avoids retaining a partially mutated or sensitive transaction name while keeping the host request available.

The shared TransactionNameProviderUtils classes are public only for cross-package integration use and are annotated @ApiStatus.Internal. Provider-list behavior remains private to CombinedTransactionNameProvider because it has no other production callers.

💚 How did you test it?

  • ./gradlew spotlessApply apiDump
  • ./gradlew :sentry-spring:test :sentry-spring-jakarta:test :sentry-spring-7:test
  • ./gradlew :sentry-spring:apiCheck :sentry-spring-jakarta:apiCheck :sentry-spring-7:apiCheck

📝 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

None.

adinauer and others added 2 commits October 9, 2026 06:27
Keep Spring requests and event capture running when a transaction name provider
throws. Use an unlabeled custom transaction as the privacy-safe fallback and
continue to later providers when resolving combined names.

Apply the same behavior across the Spring, Spring Jakarta, and Spring 7
integrations.

Co-Authored-By: Claude <noreply@anthropic.com>
@sentry

sentry Bot commented Oct 9, 2026 •

Copy link
Copy Markdown

📲 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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant