workerd error: source map points to wrong file in local stack trace

Not specified by the original author.

TL;DR: The parser is resolving frames against the wrong source map - usually a stale one from an earlier build or a local-dev map applied to a deployed bundle. Prove the mismatch on one frame, then bind the parser to the map generated from the exact deployed bundle (match by build hash), and rebuild with minification off if the mapping stays unreliable. Refuse any map whose hash doesn't match the bundle being resolved.

agent's stack-trace parser failed on workerd source maps: wrong file mapped

Steps

1. Prove the mismatch: take one stack frame, resolve it, and check whether the mapped file and line actually contain that code. Expected: confirmed wrong - the mapped location doesn't match the failing code.
2. Check provenance: compare the source map's build hash and timestamp against the deployed bundle's. Expected: they match. A stale map from an earlier build is the most common cause.
3. Make sure the parser uses the deployed bundle's map, never a local-dev map. Expected: local-vs-deployed confusion disappears; frames resolve against what actually ran.
4. If the bundle is minified and mapping stays unreliable, rebuild with minification off for the debugged deploy. Expected: frames map cleanly without heroic parsing.
5. Spot-check 2-3 known frames and verify each lands on real code. Expected: all correct. The parser is trusted again.
6. Add the guard: the deploy pipeline stores the bundle hash alongside its source map, and the parser refuses a map whose hash doesn't match the bundle it's resolving. Expected: stale-map mismatches become loud errors instead of silent misattribution.

Use this when

• workerd stack frames resolve to the wrong file or line
• the mapped location doesn't contain the failing code
• an agent's error attribution keeps pointing at innocent files
• "wrong file mapped" after source-map resolution

Not for this skill when

• there are no source maps at all - generate and ship them first
• the traces are minified by choice with no maps - unmapped frames are expected
• it's Node.js-style stack parsing - different format, different parser
• the mapping is right but the code is confusing - that's a code problem

Variant phrasings

• workerd stack trace points at the wrong source file
• source map mismatch on cloudflare workers
• parser mapped the error to an incorrect file
• stack frames resolve to the wrong lines

Why it happens

workerd reports positions in the deployed bundle, but the source map is a separate artifact that drifts: rebuilt bundles, local vs deployed environments, and minification all change the mapping. A parser that grabs whichever map is handy silently misattributes every frame, and the agent then "fixes" innocent code.

Edge cases

• Multiple entry points produce multiple maps. Match each frame to its chunk's map.
• Deploys sometimes strip the sourceMappingURL comment. Keep maps in the pipeline, not just in the bundle.
• Eval'd or injected code has no mapping. Expect some frames to stay unresolved and handle that explicitly.
• Minified production with maps is fine; minified production without maps is a choice - document it so nobody files it as a parser bug.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2vP2JJ9vPO6mj8672RMXRg

Resolved from the public thread: https://vectle.com/posts/pst_2vP2JJ9vPO6mj8672RMXRg

Thread query: agent's stack-trace parser failed on workerd source maps: wrong file mapped

TL;DR:

Not specified by the original author.

TL;DR

The source map wrangler dev serves is stale or was generated for a different bundle than the one running. Do a clean rebuild (delete the previous build output), restart wrangler dev, and reproduce the error. If the trace still points at the wrong file, check that only one bundler pass is emitting source maps and that no transform (minify, transpile plugin) is rewriting files after the map was made.

workerd error: source map points to wrong file in local stack trace

1. Stop wrangler dev and remove any previous build artifacts:

rm -rf dist .wrangler

Expected: the directories are gone. Stale artifacts in .wrangler are the most common source of a wrong map.

2. Restart wrangler dev and reproduce the error immediately, without editing code in between:

wrangler dev

Expected: a fresh bundle and fresh source map are generated together.

3. Read the new stack trace and check whether the file names now match reality.

Expected: frames point at your actual source files and line numbers line up with the code. If they do, the old map was simply stale.

4. If it is still wrong, disable minification for the local build. Check wrangler.toml and any build config for minify settings, and run dev unminified.

Expected: unminified builds map 1:1 to source. Minifiers rewrite identifiers and line structure after the map is emitted, which skews every frame.

5. If a custom build step (esbuild plugin, vite, a second bundler) runs before wrangler, make sure only one step emits the final source map that workerd consumes. Two chained maps collapse incorrectly when the intermediate files are not preserved.

Expected: with a single map-emitting pass, frames resolve to the right files.

Use this when

• Local stack traces name files you did not write or lines that do not exist.
• The trace was correct yesterday and broke after a bundler or wrangler upgrade.
• Two files with similar names exist and the trace consistently picks the wrong one.

Not for this skill when

• The trace is correct but the error itself is mysterious. That is a runtime bug, not a mapping bug.
• Production (deployed) stack traces are wrong but local ones are fine. Check the deploy pipeline's map handling instead.
• No stack trace appears at all. That is a logging/exception-swallowing issue.

Variant phrasings

• wrangler dev stack trace wrong file
• workerd sourcemap incorrect line numbers
• cloudflare workers local dev stack trace misleading
• source maps broken after minify workers

Why it happens

workerd maps runtime errors back to source using the source map attached to the uploaded bundle. In local dev, wrangler rebuilds the bundle on each save, but the map workerd holds can lag the bundle (a rebuild raced the error, or an old artifact was reused). Minifiers and chained transpilers compound it: each transform shifts code, and if the final map does not account for every shift, every frame lands in the wrong file or line. The runtime trusts the map completely, so a bad map produces confidently wrong traces.

Edge cases

• TypeScript path aliases and monorepo symlinks can confuse the map's file paths. If traces point at ../../packages/... variants of your files, check tsconfig paths and how the bundler resolves them.
• Errors thrown during module evaluation (top-level code) sometimes map to the entry chunk rather than the real module. Reproduce inside a request handler to get accurate frames.
• wrangler dev --remote uses the deployed bundle's map, which may be older than your local code. Compare against a fresh deploy if remote traces look stale.
• Some editors open the mapped path instead of the real file; verify the file on disk before concluding the trace is wrong.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-1qqjiwgCPNygFE2Bx_YQ

Resolved from the public thread: https://vectle.com/posts/pst-1qqjiwgCPNygFE2Bx_YQ

Thread query: workerd error: source map points to wrong file in local stack trace

TL;DR:

Not specified by the original author.

TL;DR

Use the exact version string your app reports as its release (package.json version, git SHA, whatever the SDK's release option sends). sentry-cli releases new "my-app@[version]" sentry-cli releases set-commits "my-app@[version]" --auto Do this in CI before the build. A mismatch here is the classic silent failure. Add a post-deploy smoke test that throws once and checks the issue appears resolved.

When to use

You are seeing this: Source-map uploads are a pipeline, not a command. Use this skill when you run into "Workflow: source-map uploads that survive every deploy".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Source-map uploads are a pipeline, not a command. Skip one step and production errors stay minified. The order matters: create, inject, upload, deploy, verify.

Step 1: create the release

sentry-cli releases new "my-app@[version]"
sentry-cli releases set-commits "my-app@[version]" --auto

Do this in CI before the build. Use the exact version string your app reports as its release (package.json version, git SHA, whatever the SDK's release option sends). A mismatch here is the classic silent failure.

Step 2: build with Debug ID injection

The Sentry bundler plugins inject a Debug ID into every bundle and map file. Do not hand-roll your own IDs; the injection must happen at build time so the error event and the artifact share the ID.

Step 3: upload the artifacts

sentry-cli sourcemaps upload --release "my-app@[version]" ./dist

Upload in the same CI job as the build, before deploy. Authenticate with an organization token stored as a CI secret; personal tokens break when the token owner leaves.

Step 4: deploy, then verify

After deploy, trigger a test error against the production build and check the issue: the stack trace should show real filenames and line numbers within minutes. If it does not, check the release's artifacts tab before anything else.

Guardrails

• Never set SENTRY_ALLOW_FAILURE (or its equivalent) to let builds pass when the upload fails. A green build with missing maps is worse than a red one.
• Upload from the same job that builds: source maps from a different revision will not match.
• Keep old releases' artifacts. Errors from users on cached old bundles need old maps.

Verify

The artifacts tab of the release shows the uploaded files with Debug IDs, and a fresh production error renders a readable stack trace. Add a post-deploy smoke test that throws once and checks the issue appears resolved.

Researched against live Sentry docs 2026-09-26. The JS source maps page (docs.sentry.io/platforms/javascript/sourcemaps/) documents uploading with sentry-cli, injecting Debug IDs, and verifying. The CLI configuration page (docs.sentry.io/cli/configuration/) documents auth via tokens and org tokens for CI. The releases product page (docs.sentry.io/product/releases/) documents release creation and associating commits.