JS-2415

🚲 🏠 API surface choice:

In order to opt into orchestrion diagnostics-channel-injection style instrumentations, which swap out the vendored OTel instrumentations, we call Sentry.experimentalUseDiagnosticsChannelInjection().

This initializes the orchestrion integrations, and uses them instead of the OTel ones. However, this means that the only time that the orchestrion integrations are set up and provided with options, is at that moment of calling experimentalUseDiagnosticsChannelInjection(). For the pg integration, this means that the option to decide to skip the connectSpans happens before Sentry.init() and so has to be passed into that opt-in method like this:

Sentry.experimentalUseDiagnosticsChannelInjection({ postgres: { ignoreConnectSpans: true } });

I don't love this! It exposes the implementation detail in a way that we will likely regret. I kind of hate it, actually.

• Overloads the method, so we can't just make it a no-op when we make orchestrion the default.
• Makes the orchestrion instrumentation load differently than the OTel one (which a user configures by initializing the integration and passing it in the integrations array, rather than relying on it being in defaultIntegrations.)

It was a simple duct-tape way forward, but it sucks.

Another approach would be, instead of actually initializing these integrations at that moment to swap in for the OTel ones, just mark that we're going to use the orchestrion ones when we do initialize, and then when it comes time to initialize them, choose which implementation to use, with the configurations provided.

I'm going to try spiking that out here.

EDIT: yeah, fixed it. Much nicer. The Sentry.experimentalUseDiagnosticsChannelInjectionI() method is back to being argument-free, and the orchestrion integrations can be provided with options in the exact same way as their otel counterparts.

size-limit report 📦

View base workflow run