AsyncLocalStorage Next.js Error with Cloudflare Workers

[logaretm]

Description

Initially reported by @tristanbes in this issue

I just had an outage on my production because of this. I am, as i'm typing this message, deleting all server side integration with sentry that I followed from your docs.

Cannot call this AsyncLocalStorage bound function outside of the request in which it was created.

Environment:

• Next.js: 15.5.9
• @opennextjs/cloudflare: 1.14.8
• @sentry/nextjs: 10.33.0
• Deployment: Cloudflare Workers
• Cloudflare Workers compatibility_date: 2025-11-17
• Cloudflare compatibility_flags: nodejs_compat, global_fetch_strictly_public

Symptoms encountered:

• AsyncLocalStorage errors when using Sentry.captureRequestError in the onRequestError hook (maybe with addBreadcrumb too)
• Server-side Sentry initialization causes silent failures or "Server failed to respond" errors

Current workaround:
I've removed all server-side Sentry integration (deleted sentry.server.config.ts and sentry.edge.config.ts) and only kept client-side error tracking via instrumentation-client.ts. Client-side Sentry works fine.

The withSentryConfig wrapper in next.config.ts still works for source map uploads and the /monitoring tunnel route.

Is there an ETA for OpenNext/Cloudflare Workers support? Would love to have full-stack observability back. Happy to help test any beta/canary versions.

I haven't reproduced it yet, but it might be related to #18700

[linear]

JS-1480

[inooid]

I've created a reproducible repo with the last working version (and a PR with the latest non-working version) if that helps. This repo simply consists of:

1. npm create cloudflare@latest -- my-next-app --framework=next
2. npx @sentry/wizard@latest -i nextjs (replacing the DSN and config with env vars)

✅ The main branch is running @sentry/nextjs@10.32.1 and is confirmed to work
❌ The update-to-10-33-0 branch is running @sentry/nextjs@10.33.0 which does not work.

In order to run:

1. Checkout the repo
2. npm install
3. Setup .env with a SENTRY_DSN
4. npm run preview to run opennextjs-cloudflare build && opennextjs-cloudflare preview
5. Head to the localhost app /sentry-example-page and/or /api/sentry-example-api (e.g. http://localhost:8788/sentry-example-page)

On main it looks like this as expected:

On update-to-10-33-0 it looks like this:

Let me know if there's anything else I can do to help out

[logaretm]

Thanks for the reproduction, it is indeed caused by #18700. I'm working on a fix right now.

[github-actions]

A PR closing this issue has just been released 🚀

This issue was referenced by PR #18889, which was included in the 10.36.0 release.

[tristanbes]

Hello,

Thanks @logaretm for creating an issue based on my initial report and @inooid for the reproducer ;
I'm using Sentry since 2014 (if remembering correctly); Mainly for Symfony (PHP backend) / Javascript (frontend). I developped a blind trust for it.

Since working with Next.js hosted in Cloudflare Workers, I only encountered weird issues/support that I never encountered with Symfony where all errors were successfully logged inside Sentry with context etc...

I'm not even talking about the 10mb HARD limit for the code to be deployed on CF Workers; With Turbopack (default since Next.js 15.x) you cannot even tweak Sentry build like you would do for Webpack to "optimize" the size of the code shipped to the production

I must admin that I lost confidence in using Sentry with Next.js / CF Workers since it crashed my production for my customers;
How can you ensure this never happens in the future (Sentry crashing the app/site) ?

Would you be open to make Sentry support for Next.js when running in CF Workers more a 1st class citizen ?

[logaretm]

@tristanbes I understand your frustration and things like this should not happen. We are already discussing ways to ensure all of our SDKs (not just Next.js) work as expected across the different runtimes in the ecosystem.

For Next.js specifically, I'm working on writing CF workers E2E tests which we didn't have before to cover this use-case and ensure we stay on top of runtime quirks with Next.js.