Skip to content

fix(compose): allow overriding the IScopes used by SentryTraced via LocalSentryScopes#5838

Open
Tabishahmad wants to merge 1 commit into
getsentry:mainfrom
Tabishahmad:fix/sentry-traced-custom-scopes
Open

fix(compose): allow overriding the IScopes used by SentryTraced via LocalSentryScopes#5838
Tabishahmad wants to merge 1 commit into
getsentry:mainfrom
Tabishahmad:fix/sentry-traced-custom-scopes

Conversation

@Tabishahmad

Copy link
Copy Markdown

SDKs that report their own telemetry through a separate IScopes/Hub instance (distinct from the host app's Sentry setup) previously had no way to make SentryTraced trace against that instance, since it always read from the global Sentry.getCurrentScopes(). LocalSentryScopes can now be overridden via CompositionLocalProvider to scope tracing to a specific IScopes, while sibling SentryTraced calls under the same scopes still share one root composition/render span.

📜 Description

Adds a public LocalSentryScopes CompositionLocal to sentry-compose, defaulting to Sentry.getCurrentScopes() and overridable via CompositionLocalProvider(LocalSentryScopes provides myScopes) { ... }.

SentryTraced now resolves the current IScopes from LocalSentryScopes instead of always reading the global default. The root "Initial Composition" / "Initial Render" spans are cached per IScopes in a shared holder so that sibling SentryTraced calls under the same scopes still share one root span (matching current behavior), while calls under different scopes each get their own independent root span.

💡 Motivation and Context

Enables SDKs/libraries that report their own telemetry through a separate IScopes/Hub instance to use SentryTraced against that instance, independently of the host app's own Sentry setup. Direction confirmed with @markushi and @romtsn on the issue.

💚 How did you test it?

Added SentryTracedTest covering:

  • spans are created on the IScopes provided via LocalSentryScopes
  • sibling SentryTraced calls under the same scopes share one root span
  • SentryTraced calls under different scopes don't interfere with each other

Existing ComposeIntegrationTests still pass.

📝 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

Update public API docs for sentry-compose once this lands, to document LocalSentryScopes.

…ocalSentryScopes

SDKs that report their own telemetry through a separate IScopes/Hub
instance (distinct from the host app's Sentry setup) previously had no
way to make SentryTraced trace against that instance, since it always
read from the global Sentry.getCurrentScopes(). LocalSentryScopes can
now be overridden via CompositionLocalProvider to scope tracing to a
specific IScopes, while sibling SentryTraced calls under the same
scopes still share one root composition/render span.

Fixes getsentry#2668
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.

Allow using a custom Hub with SentryTraced for Jetpack Compose

1 participant