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

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: Pass a valid redirect status code (301, 302, 303, 307, or 308) to Response.redirect. workerd validates the status in native code before any JavaScript frame runs, so the thrown error carries no file or line. The fix is to find the call site by searching your source for Response.redirect instead of following the stack.

Response constructor: invalid redirect value

Steps

1. Search your worker source for every redirect construction: grep -rn "Response.redirect" src worker functions Expected: a list of files and line numbers where redirects are built.

2. At each call site, read the status argument. Anything other than 301, 302, 303, 307, or 308 (for example 200, 201, or 404) is invalid and triggers this exact error. Expected: you find at least one call passing a non-redirect status.

3. Change the status to the intended redirect code, e.g. 302 for a temporary redirect or 301 for permanent. Expected: the file saves with a valid redirect status.

4. Reproduce locally with wrangler dev and hit the redirect path. Expected: a 3xx response in the browser or curl, and no "invalid redirect value" exception in the worker logs.

5. Teach the agent's parser the routing rule: match on the message text /invalid redirect value/ and jump straight to the redirect-site search; never wait for stack frames that will not come. Expected: the next occurrence triages to the right file on the first pass, even with an empty stack.

Use this when

• The exact message "Response constructor: invalid redirect value" appears in workerd logs
• The stack trace is empty, or points at native code with no file or line
• A worker builds redirects with Response.redirect
• An agent's stack parser reports "no source location" for this error

Not for this skill when

• The redirect fails with a different message, e.g. an invalid URL or too many redirects
• The error comes from a fetch to an external origin rather than Response.redirect
• The stack trace DOES contain a valid file and line (follow it instead)

Variant phrasings

• workerd "Response constructor: invalid redirect value" on 301 redirect
• workerd uncaught exception: invalid redirect value
• Response.redirect throws inside a Cloudflare Worker
• redirect status invalid in worker fetch handler

Why it happens

The fetch spec only allows the five redirect status codes in the Response constructor. workerd validates the status in its native C++ layer before any JavaScript frame executes, so the TypeError it throws has no JavaScript source location attached. Most commonly an agent or developer passes 200 (meaning "OK") or a variable holding a non-redirect status.

Edge cases

• A status passed as a string can coerce oddly; keep it a number.
• If the status comes from a variable, grep will not show the value; log it once right before the redirect call to see what is actually passed.
• Shared middleware may contain several redirect helpers; check every call site, not just the first hit.
• The same error fires from the local workerd in wrangler dev, so this rule applies in local development too.

Provenance

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

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

Thread query: agent failed to parse workerd "invalid redirect value" stack: no source location

TL;DR: