@sentry/astro: Cloudflare Worker server wrap not applied with @astrojs/cloudflare v14 (transform targets `astrojs-ssr-virtual-entry`, adapter now emits `virtual:cloudflare/worker-entry`)

[0x80]

Summary

With @astrojs/cloudflare v14, @sentry/astro's server-side init is never applied to the deployed Cloudflare Worker. The Worker's default export is left un-wrapped by withSentry, so server-side error/log capture does not initialize at the fetch boundary — server-side Sentry silently does nothing.

Versions

• @sentry/astro 10.62.0
• @sentry/cloudflare 10.62.0
• @astrojs/cloudflare 14.0.1
• astro 7.0.3
• output: 'server', Cloudflare Workers (not Pages)

Root cause

sentryCloudflareVitePlugin (packages/astro/src/integration/cloudflare.ts) wraps the Worker by transforming the module whose id contains astrojs-ssr-virtual-entry:

transform(code, id) {
  if (!id.includes("astrojs-ssr-virtual-entry")) {
    return undefined;
  }
  // ...rewrites `export default X;` -> `export default withSentry(() => undefined, X);`
}

@astrojs/cloudflare v14 builds the Worker through @cloudflare/vite-plugin, whose entry virtual module id is virtual:cloudflare/worker-entry (its generated body ends with export default mod.default ?? {};). The old astrojs-ssr-virtual-entry id is no longer produced, so the transform guard always returns early and the entry is never wrapped.

Effect

With an app configured per the Astro + Cloudflare docs (the sentry() integration in astro.config plus a sentry.server.config.ts doing export default Sentry.withSentry((env) => ({ ... }), handler)), the generated dist/server/entry.mjs default export is the raw Astro handler. Grepping all of dist/server for withSentry(() => finds no match — the plugin's wrap never ran.

The only remaining server wiring is the injected import "sentry.server.config.(ts|js)" (injectScript("page-ssr", ...)). That runs lazily during a page render, so it doesn't deterministically instrument the Worker's fetch entry:

• errors on the first request (before any page module has evaluated the config) aren't captured;
• routes that don't pull the page-ssr module graph (e.g. API endpoints) aren't covered;
• for a Worker whose first traffic is an API route, Sentry.init may never run at all.

Repro

1. Scaffold an Astro app with output: 'server' and the @astrojs/cloudflare v14 adapter (Workers, not Pages).
2. npm i @sentry/astro @sentry/cloudflare; add sentry() to integrations; create sentry.server.config.ts per the docs:

   import * as Sentry from '@sentry/cloudflare'
   import handler from '@astrojs/cloudflare/entrypoints/server'
   export default Sentry.withSentry((env) => ({ dsn: env.SENTRY_DSN, enableLogs: true }), handler)

3. astro build.
4. Inspect dist/server/entry.mjs: the default export is the un-wrapped Astro handler, and grep -r "withSentry(() =>" dist/server returns nothing.

Suggested fix

Have sentryCloudflareVitePlugin's transform also match the @cloudflare/vite-plugin entry id virtual:cloudflare/worker-entry (whose default-export expression is mod.default ?? {}), in addition to astrojs-ssr-virtual-entry, so the wrap applies on @astrojs/cloudflare v14+.

Workaround

For anyone hitting this before a fix lands: a tiny build-only Vite plugin that transforms the virtual:cloudflare/worker-entry module and wraps its export default mod.default ?? {}; with your own withSentry(optionsCallback, handler) restores deterministic, eager wrapping of the Worker entry.

[linear-code]

JS-2893

[JPeer264]

How does your wrangler.jsonc look like? I think you might have missed the step where you change the entrypoint for wrangler:

https://docs.sentry.io/platforms/javascript/guides/cloudflare/frameworks/astro/#configure-custom-entry-point

{
  "main": "./sentry.server.config.ts",
}

[0x80]

Thanks! I'm not using the custom entry point — my deploy uses the adapter's generated Worker entry (dist/server/entry.mjs) directly rather than pointing wrangler's main at a sentry.server.config.ts. Pointing main at a custom entry would sidestep the problem (that export does still exist on v14), but it's a different mechanism from the sentry() integration's automatic server wrap, which is what this issue is about.

The integration still installs sentryCloudflareVitePlugin on v14, but its transform only matches an id containing astrojs-ssr-virtual-entry — which v14 no longer emits. v14 builds the Worker through @cloudflare/vite-plugin, whose entry is virtual:cloudflare/worker-entry (body ending export default mod.default ?? {};). So the guard returns early, the generated entry ships un-wrapped, and server-side Sentry.init never runs at the fetch boundary — silently, with no build warning.

The custom entry point is a fine workaround, but an integration that installs a wrap matching nothing and capturing nothing is a footgun on its own. Two directions that would fix the actual regression:

• Have the transform also match the v14 entry id virtual:cloudflare/worker-entry (default-export expression mod.default ?? {}), in addition to astrojs-ssr-virtual-entry, so the auto-wrap fires again on v14+; and/or
• Warn/error at build time when the integration produced a Cloudflare Worker entry it couldn't wrap, so this fails loud instead of silently doing nothing.

Happy to test a patch against @astrojs/cloudflare v14 if that helps.