You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
@sentry/sveltekit 11: orchestrion build-time transform emits a module-relative source without sourcesContent, breaking server source map flattening #25329
SvelteKit app with sentrySvelteKit() in vite.config.ts (v11 auto-adds the orchestrion bundler plugin) and server code that imports a dependency orchestrion instruments, e.g. ioredis or the Vercel AI SDK (ai).
vite build with build.sourcemap: true.
Inspect the SSR output map of a chunk that bundles the instrumented module, e.g. .svelte-kit/output/server/entries/endpoints/<route>/_server.ts.js.map.
Expected Result
Every entry in sources resolves to a real file (or has sourcesContent), so source map flattening (Sentry's own sorcery pass in uploadSourceMaps, or any chaining tool) can follow the chain back to the original sources.
Actual Result
Next to the real entry for the instrumented file, the map contains an extra, module-relative source with no sourcesContent:
480 '../../../../../../../../node_modules/.pnpm/ioredis@5.11.1_<hash>/node_modules/ioredis/built/Redis.js' (has sourcesContent)
481 '../../../../../../../../ioredis/built/Redis.js' (NO sourcesContent)
The second path resolves to <project root>/ioredis/built/Redis.js, which does not exist. The same happens for ai/dist/index.mjs. Any flattening step then fails for the whole chunk:
ENOENT: no such file or directory, open '<project root>/ioredis/built/Redis.js'
ENOENT: no such file or directory, open '<project root>/ai/dist/index.mjs'
uploadSourceMaps() in @sentry/sveltekit/build/esm/vite/sourceMaps.js catches this as a "known" ENOENT and moves on, so the uploaded map for that chunk is left unflattened and stack frames from it resolve to the intermediate SvelteKit/adapter output instead of src/. In our app this affects exactly the chunks that bundle an orchestrion-instrumented dependency (2 of ~1,300 server chunks); a build of the same app on @sentry/sveltekit 10.75.3 does not have these two failures.
Likely cause, in the vendored @apm-js-collab/code-transformer/lib/transformer.js (Transformer#transform):
When the module has no input source map (true for ioredis/built/Redis.js), the generated map names its source with the module-relative file and never calls setSourceContent, and the bundler keeps that name verbatim. Using the transformed module's absolute id as the source name, or embedding the original code as sourcesContent, would make the map self-contained. Returning map: null when the transform only inserts code without moving it might also be enough for Vite/Rolldown to keep the original mapping.
Additional Context
Found while upgrading a production SvelteKit 2 app from @sentry/sveltekit 10 to 11. Happy to test a fix.
Hey @andre-salata thanks for reporting! It seems this bug needs to be fixed upstream in the orchestrion or the code transform plugin. Gonna look a bit into this.
This seems to be a general issue with Orchestrion writing incorrect source paths into the source maps of the files it transforms. It's noticeable in SvelteKit because we look into that source map with sourcery to flatten the multi-step build the node adapter does.
Activity
linear-code commentedon Oct 13, 2026
JS-3928
Lms24 commentedon Oct 13, 2026
Hey @andre-salata thanks for reporting! It seems this bug needs to be fixed upstream in the orchestrion or the code transform plugin. Gonna look a bit into this.
This seems to be a general issue with Orchestrion writing incorrect source paths into the source maps of the files it transforms. It's noticeable in SvelteKit because we look into that source map with sourcery to flatten the multi-step build the node adapter does.