agent failed to parse workerd invalid redirect value stack: no sourc

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:

Not specified by the original author.

TL;DR

When workerd throws "invalid redirect value" and your own code looks correct, the next step is checking whether it is a known upstream bug. Search the cloudflare/workerd GitHub issues for that exact string, open the matching issue, and read the repro, the maintainer response, and any linked fix. Most of the time you will find either a confirmed bug with a workaround or a "working as intended" reply that points at the real mistake in your redirect.

site:github.com/cloudflare/workerd "invalid redirect value"

Steps

1. Search the workerd issue tracker for the exact error string:

gh issue list --repo cloudflare/workerd --search "invalid redirect value" --limit 20

Expected: a short list of issues whose titles or bodies contain the string. If the gh CLI is not set up, the same search works in the GitHub web UI on the cloudflare/workerd repo.

2. Open the top matches and compare the stack trace and repro to yours. Look for the maintainer's label: confirmed bug, duplicate of another issue, or closed as expected behavior.

Expected: you can tell within a few minutes whether your case matches a known report or is new.

3. If it matches a known issue, check for linked pull requests and the release they landed in, then check your wrangler's workerd version against that release.

Expected: either a fix version you can upgrade to, or a posted workaround you can apply now.

4. If nothing matches, file a new issue with a minimal repro: the smallest worker that throws, the workerd version from wrangler --version, and the full stack.

Expected: the report is actionable for maintainers instead of another vague "redirect broken" post.

Use this when

• Workerd throws "invalid redirect value" and your redirect code looks right
• You want to know if the error is a known workerd bug before rewriting your code
• You need the upstream workaround or the fix version

Not for this skill when

• The redirect target is a relative URL you control; fix it with an absolute URL instead (see the Response.redirect skill)
• The error comes from your own framework's redirect helper, not workerd
• You already found the matching issue and just need the fix

Variant phrasings

• cloudflare workerd invalid redirect value github issue
• workerd Response redirect throws invalid redirect value bug
• "invalid redirect value" cloudflare workers issue tracker

Why it happens

The "invalid redirect value" error sits exactly on the boundary between user error (relative or malformed redirect targets) and runtime strictness (workerd enforcing the spec harder than browsers do). That boundary is where upstream bugs live, so the issue tracker is often the fastest route to an answer.

Edge cases

• An issue closed as "working as intended" usually means the reporter passed a relative URL; re-check your redirect target before assuming a bug.
• Duplicate issues get closed fast; search before filing so your report lands on the live thread.
• The fix version in a merged PR may not be in the wrangler release you have; check the changelog rather than assuming.
• Workerd behavior can differ between local dev and deployed; note which one your repro uses when comparing with an issue.

Provenance

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

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

Thread query: site:github.com/cloudflare/workerd "invalid redirect value"

TL;DR: When workerd throws "invalid redirect value" and your own code looks correct, the next step is checking whether it is a known upstream bug. Search the cloudflare/workerd GitHub issues for that exact string, open the matching issue, and read the repro, the maintainer response, and any linked fix. Most of the time you will find either a confirmed bug with a workaround or a "working as intended" reply that points at the real mistake in your redirect.

Not specified by the original author.

TL;DR

Response.redirect requires an absolute URL, and workerd throws the moment you hand it a relative path like "/login". Browsers are lenient about this in some paths, workerd is not. Build the target with new URL(path, request.url) so it is always absolute, then redirect.

TypeError: Response constructor: invalid redirect value

Steps

1. Find the throwing redirect call. Search your worker for Response.redirect:

grep -rn "Response.redirect" src

Expected: one or more call sites; the throwing one passes a relative path or a malformed string.

2. Make the target absolute using the incoming request as the base:

const url = new URL("/login", request.url);
return Response.redirect(url.toString(), 301);

Expected: no relative paths reach Response.redirect anywhere in the handler.

3. Confirm the status code is a real redirect status: 301, 302, 303, 307, or 308. Anything else with a Location header trips the same validation.

Expected: the status is one of those five.

4. Test locally and check the response:

wrangler dev

Then request the redirecting route and confirm you get a 301 with a correct absolute Location header. Expected: 301 status, Location header present and absolute, no exception in the dev log.

Use this when

• Workerd throws "Response constructor: invalid redirect value" on a redirect
• A redirect that works in the browser throws inside the worker
• You are constructing redirect targets from user input or route params

Not for this skill when

• The redirect returns but points at the wrong place; that is a logic bug, not this error
• The error comes from a framework helper rather than a direct Response.redirect call
• You are investigating whether it is a workerd bug (use the issue-search skill)

Variant phrasings

• TypeError invalid redirect value workerd
• Response.redirect throws in cloudflare worker
• workerd redirect Location header invalid

Why it happens

The Fetch spec requires redirect responses to carry a valid absolute URL, and workerd validates the value strictly at construction time. A relative path fails URL parsing, so the constructor throws instead of returning a broken response. Code that ran fine in Node or the browser, where some redirect paths tolerate relative targets, breaks on this strictness.

Edge cases

• Redirect targets built from user input can contain spaces or unicode; encode them before constructing the URL or the parse fails the same way.
• In tests, request.url may be a fake origin; make sure the base you pass to new URL is a valid absolute URL or the helper throws instead.
• 307 and 308 preserve the request method; switching status codes to dodge the error changes semantics, so fix the URL instead.
• Middleware that rewrites the Location header after the redirect is constructed can reintroduce a relative value; check the final response, not just the constructor call.

Provenance

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

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

Thread query: workerd "Response constructor: invalid redirect value" on 301 redirect

TL;DR: Response.redirect requires an absolute URL, and workerd throws the moment you hand it a relative path like "/login". Browsers are lenient about this in some paths, workerd is not. Build the target with new URL(path, request.url) so it is always absolute, then redirect.