Description
A Next.js app on Cloudflare Workers that initializes @sentry/nextjs in instrumentation.ts and also wraps the Worker entry with @sentry/cloudflare's withSentry fails on every request:
TypeError: e.getValue is not a function
at getScopesFromContext
at getScopes
...
at _onSpanEnded
at end
Seen with @sentry/nextjs@11.0.0-rc.1 and @sentry/cloudflare@11.0.0-rc.1, which share the same @sentry/core.
Root cause
The two SDKs install different async context strategies, and the second one reuses the AsyncLocalStorage of the first even though the two strategies put different things into it:
| Strategy |
Installed by |
ALS store |
setAsyncLocalStorageAsyncContextStrategy (packages/server-utils/src/async-context.ts) |
@sentry/cloudflare (withSentry) |
{ scope, isolationScope } |
setOpenTelemetryContextAsyncContextStrategy (packages/opentelemetry/src/asyncContextStrategy.ts) |
@sentry/nextjs edge build (via @sentry/vercel-edge) |
an OpenTelemetry Context, also read by the global context manager it registers |
Both pick up an existing store like this, without checking which strategy created it (added in #22889):
const existing = getAsyncContextStrategy(getMainCarrier()).getTracingChannelBinding?.()?.asyncLocalStorage;
const asyncLocalStorage = existing ?? new AsyncLocalStorage();
Once the stores are shared, api.context.active() returns the plain { scope, isolationScope } object, and getScopesFromContext(ctx) (or trace.getSpan(ctx)) calls ctx.getValue() on it. It fails in both install orders.
Reproduction
No framework needed:
import { getCurrentScope, withIsolationScope } from '@sentry/core';
import { setAsyncLocalStorageAsyncContextStrategy } from '@sentry/cloudflare';
import { setOpenTelemetryContextAsyncContextStrategy } from '@sentry/opentelemetry';
setAsyncLocalStorageAsyncContextStrategy();
withIsolationScope(() => {
setOpenTelemetryContextAsyncContextStrategy();
getCurrentScope(); // TypeError: context.getValue is not a function
});
The reverse order fails the same way:
import { context, trace } from '@opentelemetry/api';
setOpenTelemetryContextAsyncContextStrategy();
setAsyncLocalStorageAsyncContextStrategy();
withIsolationScope(() => {
trace.getSpan(context.active()); // TypeError: context.getValue is not a function
});
Expected
A strategy only reuses an AsyncLocalStorage that holds the store shape it expects, for example by tagging the binding with its store type and creating a fresh ALS on a mismatch.
This only stops the crash. Two SDKs in one runtime still end up with one active strategy and one current client, so combining @sentry/nextjs and @sentry/cloudflare stays unsupported. It would still be better to fail soft than to break every request. The same clash can happen with any other pair of SDKs that use different strategies.
Description
A Next.js app on Cloudflare Workers that initializes
@sentry/nextjsininstrumentation.tsand also wraps the Worker entry with@sentry/cloudflare'swithSentryfails on every request:Seen with
@sentry/nextjs@11.0.0-rc.1and@sentry/cloudflare@11.0.0-rc.1, which share the same@sentry/core.Root cause
The two SDKs install different async context strategies, and the second one reuses the
AsyncLocalStorageof the first even though the two strategies put different things into it:setAsyncLocalStorageAsyncContextStrategy(packages/server-utils/src/async-context.ts)@sentry/cloudflare(withSentry){ scope, isolationScope }setOpenTelemetryContextAsyncContextStrategy(packages/opentelemetry/src/asyncContextStrategy.ts)@sentry/nextjsedge build (via@sentry/vercel-edge)Context, also read by the global context manager it registersBoth pick up an existing store like this, without checking which strategy created it (added in #22889):
Once the stores are shared,
api.context.active()returns the plain{ scope, isolationScope }object, andgetScopesFromContext(ctx)(ortrace.getSpan(ctx)) callsctx.getValue()on it. It fails in both install orders.Reproduction
No framework needed:
The reverse order fails the same way:
Expected
A strategy only reuses an
AsyncLocalStoragethat holds the store shape it expects, for example by tagging the binding with its store type and creating a fresh ALS on a mismatch.This only stops the crash. Two SDKs in one runtime still end up with one active strategy and one current client, so combining
@sentry/nextjsand@sentry/cloudflarestays unsupported. It would still be better to fail soft than to break every request. The same clash can happen with any other pair of SDKs that use different strategies.