With the basic setup of the SpanProcessor, you can get into an infinite loop quickly:

• You have some OTEL auto-instrumentation set up
• This auto-instrumentation captures outgoing HTTP requests (e.g. @opentelemetry/instrumentation-http)
• You setup the Sentry<>OTEL integration
• For any OTEL span created, we capture this to Sentry
• This is sent to Sentry as an outgoing HTTP request
• Which again is captured by the OTEL auto-instrumentation, ....

The "cleanest" way to avoid this is to setup your auto-instrumentation to skip Sentry requests, e.g.:

const sdk = new opentelemetry.NodeSDK({
  traceExporter: new OTLPTraceExporter(),
  instrumentations: [ 
    getNodeAutoInstrumentations({
      // load custom configuration for http instrumentation
      '@opentelemetry/instrumentation-http': {
        ignoreOutgoingRequestHook: (request) => {
          const host = request.host || request.hostname;
          // Ignore Sentry API calls
          return host.indexOf('.sentry.io') > -1;
        }
      },
    }), 
  ],
  spanProcessor: new SentrySpanProcessor()
})

However, this also means you need to make sure to cover any potential place where this is auto-instrumented, and it also makes the setup experience for users harder than necessary.

Instead, this PR adds some handling to handle these cases automatically.

Actual solution

Any transaction/span that we identify as being an HTTP request to the configured Sentry DSN is never finished, and thus never sent to Sentry.

Known downsides

Any theoretical child spans of the Sentry HTTP request span will also never be sent to Sentry. This shouldn't actually happen that much, or be of high relevance if it happens, but it is theoretically possible.

Explanation

At least as of now, there is simply no way in onStart of the SpanProcessor to access the attributes, as they are only set after onStart has been called. Because of this, any behavior where we handle this/properly filter this out before the span ends is not possible to implement.

We will need to do some testing to ensure there are no memory leaks (it should be fine, but to be sure...)

ref #6112

References

• @opentelemetry/instrumentation-http
• tracer.startSpan()
• calling of onStart hook