Skip to content

@sentry/sveltekit 11: orchestrion build-time transform emits a module-relative source without sourcesContent, breaking server source map flattening #25329

Open

Description

@andre-salata

Is there an existing issue for this?

How do you use Sentry?

Sentry SaaS (sentry.io)

Which SDK are you using?

@sentry/sveltekit

SDK Version

11.6.0 (the vendored @apm-js-collab/code-transformer/lib/transformer.js is byte-identical in 11.7.0)

Framework Version

@sveltejs/kit 2.70.3, @sveltejs/adapter-node 5.5.7, Vite 8.3.1 (Rolldown), Node 24, pnpm 11 (isolated node_modules/.pnpm)

Steps to Reproduce

  1. 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).
  2. vite build with build.sourcemap: true.
  3. 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):

const file = `${moduleName}/${filePath}`;        // e.g. "ioredis/built/Redis.js"
generator = sourcemap
  ? SourceMapGenerator.fromSourceMap(consumer)    // consumer.file = file
  : new SourceMapGenerator({ file });
const code2 = generate(ast, { sourceMap: generator });

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.

Activity

  1. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Oct 13, 2026
  2. linear-code commented on Oct 13, 2026

    @linear-code
  3. Lms24 commented on Oct 13, 2026

    @Lms24
    Member

    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.

  4. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions