TypeError: `b.setEntry is not a function` SentryPropagator when Supabase URL is in `tracePropagationTargets`

[felixgabler]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nuxt

SDK Version

9.16.1

Framework Version

Nuxt 3.17.2

Link to Sentry event

No response

Reproduction Example/SDK Setup

Our Nuxt 3 application uses @sentry/nuxt (which includes @sentry/opentelemetry, observed with Sentry SDK version ~9.16.1). Server-side Sentry is initialized as follows in sentry.server.config.ts:

// Path: sentry.server.config.ts
import * as Sentry from '@sentry/nuxt';
import supabase from '@supabase/supabase-js';
import dotenv from 'dotenv';

dotenv.config();

Sentry.init({
    enabled: process.env.NODE_ENV === 'production', // Error observed in Vercel (production-like)
    environment: process.env.NODE_ENV,
    dsn: process.env.SENTRY_DSN,
    integrations: [Sentry.supabaseIntegration({ supabaseClient: supabase.SupabaseClient })],
    tracesSampleRate: 1,
    // CRITICAL: Error occurs when process.env.SUPABASE_URL is included here
    tracePropagationTargets: [/^\/(?!\/)/, process.env.SUPABASE_URL!],
    // If process.env.SUPABASE_URL is removed from the array above, the error does NOT occur.
});

The project also includes several @opentelemetry/* packages. The key ones present in the environment where the error occurs are (versions approximate, based on bun pm ls):

• @opentelemetry/api: ~1.9.0
• @opentelemetry/core: ~1.30.1
• @opentelemetry/sdk-trace-base: ~1.30.1
• @opentelemetry/semantic-conventions: ~1.32.0
• @opentelemetry/instrumentation-http: ~0.57.2
• @opentelemetry/instrumentation-undici: ~0.10.1 (also tried with 0.11.0, error persists with both if Supabase URL is a propagation target)
• @opentelemetry/sdk-node: ~0.57.2
• @opentelemetry/sdk-logs: ~0.57.2

Note the mix of OpenTelemetry 1.x SDK components (which align with @sentry/opentelemetry peer dependencies) and newer 0.x generation instrumentations/SDK components. The application uses @supabase/supabase-js to interact with a Supabase backend.

Steps to Reproduce

1. Configure Sentry's tracePropagationTargets to include the application's Supabase URL (process.env.SUPABASE_URL).
2. Initialize Sentry on the server as shown in the setup, including Sentry.supabaseIntegration.
3. In a server-side API route or handler, make a call to the Supabase database using the supabase-js client (e.g., a simple await supabaseClient.from('some_table').select('*')).
4. This setup primarily fails in a Vercel deployment environment.

Expected Result

The Supabase client's HTTP request should be successfully instrumented. If the Supabase URL is a tracePropagationTarget, Sentry trace headers should be injected into the outgoing request to Supabase, and the application should function normally without crashing.

Actual Result

When the supabase-js client makes an HTTP request to the Supabase URL (which uses undici under the hood), and this URL is listed in tracePropagationTargets, the application crashes with the following error:

Uncaught Exception: TypeError: b.setEntry is not a function
at file:///var/task/node_modules/@sentry/opentelemetry/build/esm/index.js:717:20
at Array.reduce (<anonymous>)
at SentryPropagator.inject (file:///var/task/node_modules/@sentry/opentelemetry/build/esm/index.js:715:56)
at PropagationAPI.inject (/var/task/node_modules/@opentelemetry/api/build/src/api/propagation.js:62:44)
at UndiciInstrumentation.onRequestCreated (/var/task/node_modules/@opentelemetry/instrumentation-undici/build/src/undici.js:193:27) // Line number might vary
// ... rest of undici/Node.js internal stack

Workaround:
The error does not occur if:

1. The Supabase URL (process.env.SUPABASE_URL) is removed from the tracePropagationTargets array in the Sentry initialization.
   OR
2. Sentry is disabled entirely on the server-side.

This strongly suggests an incompatibility when SentryPropagator attempts to inject trace headers into requests destined for the Supabase URL, specifically in an environment with mixed OpenTelemetry versions (Sentry expecting OTel 1.x context, while instrumentation-undici is from the OTel 0.x line).

[mydea]

Hey, thanks for raising this.

0.x and 1.x should be compatible, the 0.x packages are simply "experimental" but also use the 1.x versions of core otel packages, this all seems fine to me 🤔

Some additional questions:

1. Does the problem also persist if you remove the supabaseIntegration()?
2. Does the problem happen locally too or only when deploying to vercel, on production?

[mydea]

Also to clarify: Are you using a custom OTEL setup in this app, or only OTEL via Sentry.init()? Because we do not use @opentelemetry/sdk-node or @opentelemetry/sdk-logs ourselves, so curious where this would come from 🤔

[felixgabler]

Thanks for getting back so quickly!

Hey, thanks for raising this.

0.x and 1.x should be compatible, the 0.x packages are simply "experimental" but also use the 1.x versions of core otel packages, this all seems fine to me 🤔

Some additional questions:

1. Does the problem also persist if you remove the supabaseIntegration()?

It does persist. It always happens when the supabase URL is in the tracePropagationTargets.

2. Does the problem happen locally too or only when deploying to vercel, on production?

It only happens on Vercel in production

[felixgabler]

Also to clarify: Are you using a custom OTEL setup in this app, or only OTEL via Sentry.init()? Because we do not use @opentelemetry/sdk-node or @opentelemetry/sdk-logs ourselves, so curious where this would come from 🤔

Very curious indeed. We only use the server config as shared above. No custom OTEL setup.

[mydea]

OK I see, I would assume it has nothing to do with supabase then, and only with propagation 🤔 the dependencies are very weird though, could you by chance share your package.json dependencies? Then we can try to reproduce this... but this seems vercel specific, haven't seen this one before!