Integrate Sentry OTel with External Context Storage Providers

[gilday]

Problem Statement

When using Sentry SDK 8.0.0+ with frameworks that provide their own OpenTelemetry ContextStorageProvider implementations (like Quarkus), we experience initialization conflicts:

WARNING: ContextStorageProvider initialized failed. Using default
java.lang.IllegalStateException: Found multiple ContextStorageProvider. Set the io.opentelemetry.context.ContextStorageProvider property to the fully qualified class name of the provider to use.
This occurs because both Sentry and frameworks like Quarkus register their own ContextStorageProvider implementations, but OpenTelemetry can only use one.

Please provide official support for integrating Sentry's OpenTelemetry implementation with external ContextStorageProvider implementations. Specifically:

1. An option to configure Sentry to use an existing ContextStorageProvider instead of registering its own
2. Clear documentation on how to properly integrate Sentry with frameworks that have their own OpenTelemetry context implementations
3. Hooks or extension points for customizing how Sentry interacts with OpenTelemetry context

Quarkus applications need the Quarkus ContextStorageProvider for proper Vert.x integration and reactive context propagation. Meanwhile, Sentry needs access to the context for proper scope and tracing management.
We would like to use Sentry's rich error reporting capabilities while preserving the framework's context propagation mechanisms.

Solution Brainstorm

To workaround this issue, we're considering:

1. Setting the system property to use the Quarkus provider (but unsure if Sentry will function properly)
2. Creating a combined provider that wraps both implementations (complex and potentially fragile)

Official support would provide a cleaner, maintainable solution for all Sentry users working with these frameworks.

[adinauer]

Thanks for opening this issue @gilday. Unfortunately we noticed some problems with the default OpenTelemetry ThreadLocalContextStorage due to it not restoring the previous Context whenever the current value of the ThreadLocal on close is not what it expects. Therefore we replaced it with our own implementation SentryOtelThreadLocalStorage which we then wrap with SentryContextStorage for hooking in our Scopes forking code.

Quickly glancing at https://github.com/quarkusio/quarkus/blob/main/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/QuarkusContextStorage.java it looks like there also is such check in place:
https://github.com/quarkusio/quarkus/blob/95fa5c645c6ff9032b10797924085528907be061/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/QuarkusContextStorage.java#L77-L81

Options I can quickly come up with:
A. Add an option that makes Sentry wrap a specific ContextStorage.
A1. Option to specify the ContextStorage directly
A2. Option to specify a ContextStorageProvider which we call .get() on and wrap the result

B. Fix Sentry to be able to use any ContextStorage even if it checks whether the current ThreadLocal value is as expected.

C. Add a config option to Quarkus disabling the check in https://github.com/quarkusio/quarkus/blob/95fa5c645c6ff9032b10797924085528907be061/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/QuarkusContextStorage.java#L77-L81

D. We already had a ContextStorage wrapper in place before but it turned out problematic due to having to register it early enough. Here's the PR where we replaced it #3938 . Maybe there's a way to work around the requirement to configure it early.

To close this issue we'd have to go with Option "A" and either "B" or "C".
In general I'd say it's preferable to fix Sentry ("B") but I'm not sure we can achieve that in a reasonable amount of time.
If we make this configurable in Sentry without "B", we'd have to add a big WARNING sign.
Would you be open for option "C" in Quarkus?

We'll have to discuss with the team as this can easily break the Sentry OpenTelemetry integration.

[adinauer]

Some more questions @gilday

• Do you use sentry-opentelemetry-agent? I guess not since https://quarkus.io/guides/opentelemetry recommends not to use it.
• Do you use sentry-opentelemetry-agentless (but not sentry-opentelemetry-agentless-spring)?

NOTE: None of the following has been tested. It's just an idea:
We could try to use SPI to read all implementations of io.opentelemetry.context.ContextStorageProvider, exclude our own and call .get() on whichever other one may have been defined, falling back to our own SentryOtelThreadLocalStorage instance if no others can be found. Optionally we could make this behaviour opt-in/opt-out.

The application needs to be configured to use our ContextStorageProvider and not the quarkus one (or whatever other framework might be there) to resolve the init problem you mentioned.

[adinauer]

Option "D" could be an alternative to option "A" but would likely require changes in OpenTelemetry to support SPI for ContextStorage wrappers (if that doesn't exist yet).

[gilday]

No, I do not use the OTel agent. That's right, the Quarkus OTel guide recommends that Quarkus apps do not use the agent. Also, my previous experience developing a Java agent informs my decision to avoid the agent: I do not trust that an agent can reliably propagate context in a way that mirrors Quarkus' complex context propagation: better to let the deeper Quarkus OTel integration handle that.

I am looking to include the Quarkus Opentelemetry Exporter for Sentry extension in my Quarkus project that uses Sentry 8.8.0 for error reporting.

To that end, I've tried upgrading the extension (see my fork) to use Sentry 8.8.0. The extension has an integration test that reproduces the conflict. The extension does not use sentry-opentelemetry-agentless; rather, it depends on sentry-opentelemetry-bootstrap and sentry-opentelemetry-core.

I think option A2 feels right to me. I imagine the app would set system property io.opentelemetry.context.ContextStorageProvider to specify that OTel should use the Sentry context storage provider should be used. Then, the app could also include a Sentry configuration property that instructs the SentryContextStorageProvider to select a specific io.opentelemetry.context.ContextStorageProvider instead of using the SentryOtelThreadLocalStorage that it would otherwise use.