Cannot upload Cloudflare worker.js sourcemaps when using OpenNext

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/nextjs

SDK Version

10.34.0

Framework Version

Next 15.5.9 (OpenNext + Cloudflare Workers)

Link to Sentry event

https://dogs-unleashed-ab.sentry.io/issues/93718351/events/f3276ea43fa8497c8d2ff2f00fa645eb/

Reproduction Example/SDK Setup

App is a Next 15.5.9 Pages app deployed via OpenNext to Cloudflare Workers.

Setup summary:

Build: opennextjs-cloudflare build
Wrangler build output: wrangler deploy --outdir .wrangler-sourcemaps --upload-source-maps ...
Debug IDs injected: sentry-cli sourcemaps inject .wrangler-sourcemaps
Upload: sentry-cli sourcemaps upload --debug-id-reference --rewrite .wrangler-sourcemaps
Worker deployed using the same bundle (no re-bundling):
wrangler deploy .wrangler-sourcemaps/worker.js --no-bundle ...

Artifacts are uploaded and visible in Sentry, including ~/worker.js and ~/worker.js.map with Debug IDs.

Steps to Reproduce

Deploy Next 15.5.9 using OpenNext on Cloudflare Workers.
Generate + upload sourcemaps for worker.js with Debug IDs (sentry-cli inject + upload).
Trigger an error in getServerSideProps.

Expected Result

Readable stack traces mapped to original source (e.g., pages/sentry-server-test.tsx).

Actual Result

Sentry still shows worker.js frames and says:

“Stack frame doesn’t have Debug IDs”
“Uploaded files not deployed”

Example (screenshot):

Additional Context

I can confirm:

Debug IDs exist in worker.js and worker.js.map.
The deployed worker file is the same artifact used for upload.
Sentry release is set and consistent.

Seems like the runtime frames in the event don’t include Debug IDs, even though the bundle contains them. Is @sentry/nextjs (or OpenNext) stripping debug ID metadata in the runtime stack frames for Cloudflare Workers?

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

JS-1655

@Livijn

Hey @Livijn, thanks for raising this as a follow up.

@logaretm I assigned you since you were looking into it.

@logaretm

@logaretm I am also experiencing this in my NextJS + SST setup:

If I try to deploy with withSentryConfig(nextConfig, {...}) enabled in next.config.js, I get the following error:


┌──────────────────────────────┐
│ OpenNext — Generating bundle │
└──────────────────────────────┘

Bundling middleware function...
Bundling static assets...
Bundling cache assets...
Building server function: default...
file:///private/var/folders/cz/2jxz3hfs1w7czmcp87d0l50c0000fn/T/open-next-tmpbgBnDF/next.config.mjs:11
  throw Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "fs" is not supported

@jcohenho

@jcohenho could you create a new issue for this to avoid hijacking the original issue here?

Yep, I created this opennextjs/opennextjs-cloudflare#1124 moments ago

@logaretm

@logaretm I created the separate issue here

Possible root cause, and it looks like it sits upstream of the SDK.

@opennextjs/cloudflare never emits a source map from its server bundling pass. In v1.20.2 (current latest), dist/cli/build/bundle-server.js calls esbuild with bundle, outfile, format, target, minify*, legalComments, metafile and conditions — no sourcemap. grep -rni "sourcemap" over the entire installed package returns nothing, and there is no config option to turn it on.

So the chain is already broken before Sentry is involved:

TS source -> next build (minified, maps exist)
          -> opennextjs-cloudflare esbuild   <-- no map emitted
          -> wrangler esbuild -> deployed worker.js

Injecting Debug IDs into the final bundle and uploading its map does produce a valid, self-consistent artifact — which matches the report here that the IDs are demonstrably present in both worker.js and worker.js.map, and that the deployed artifact matches the uploaded one. But that map only describes the wrangler pass. There is no map carrying positions back through the OpenNext pass to .next/server/*, so frames cannot resolve to original source regardless of what the SDK does.

If that holds, the fix likely needs to land in opennextjs-cloudflare rather than in @sentry/nextjs. I've filed it there as opennextjs/opennextjs-cloudflare#1352 asking for source-map emission from that pass.

Observed on next 16.2.12 / @opennextjs/cloudflare 1.20.2 / @sentry/nextjs 10.63.0.

Navigation Menu

Repository navigation

Cannot upload Cloudflare worker.js sourcemaps when using OpenNext #19213

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

Reproduction Example/SDK Setup

Steps to Reproduce

Expected Result

Actual Result

Additional Context

Priority

12 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Cannot upload Cloudflare worker.js sourcemaps when using OpenNext #19213

Description

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

Reproduction Example/SDK Setup

Steps to Reproduce

Expected Result

Actual Result

Additional Context

Priority

Activity

linear commented on Feb 6, 2026

andreiborza commented on Feb 6, 2026

jcohenho commented on Feb 9, 2026

logaretm commented on Feb 9, 2026

12 remaining items

logaretm commented on Feb 11, 2026

jcohenho commented on May 17, 2026

FriendlyCityJohnstown commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions