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

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: 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

Cloudflare Workers (the workerd runtime) only implements two fetch redirect modes: "follow" and "manual". If your code or a library passes redirect: "error", workerd throws a TypeError synchronously, before any request is sent. Replace "error" with "manual" and check for 3xx statuses yourself. That preserves the no-auto-follow intent on every runtime.

The exact error

TypeError: Invalid redirect value, must be one of "follow" or "manual" ("error" won't be implemented since it does not make sense at the edge; use "manual" and check the response status code).

Steps

1. Find who passes the bad value. Search your code and your dependencies for redirect: "error" or redirect: 'error'. It is often a library, not your code: @slack/web-api, connect-web based clients, @better-auth/sso v1.6.16+, and hand-rolled SSRF-hardened fetch wrappers are all confirmed offenders. Expected outcome: you locate at least one call site, frequently inside node_modules.
2. If it is your code, switch to "manual" and handle 3xx explicitly:

const res = await fetch(url, { redirect: "manual" });
if (res.status >= 300 && res.status < 400) {
  throw new Error("unexpected redirect to " + res.headers.get("location"));
}

Expected outcome: the fetch no longer throws at the call site, and a redirect becomes a rejected non-ok response, which is the same anti-SSRF posture "error" was meant to give.

3. If it is a library you cannot patch, wrap fetch with an adapter that normalizes only the unsupported value:

const workerdFetch = (url, init) =>
  globalThis.fetch(url, {
    ...init,
    redirect: init && init.redirect === "error" ? "manual" : init && init.redirect,
  });

Pass it as the fetch option the SDK exposes (for example new WebClient(process.env.SLACK_BOT_TOKEN, { fetch: workerdFetch })). Expected outcome: the SDK keeps working, and a redirect still surfaces as a non-200 response its existing error handling already rejects.

4. Verify under workerd, not just Node. Node's undici accepts redirect: "error", so unit tests and CI pass while production Workers throw. Run the affected path with miniflare or @cloudflare/vitest-pool-workers. Expected outcome: the exact TypeError reproduces in the test if the fix is incomplete, and disappears once it is complete.
5. Confirm zero-request behavior is gone. The hallmark of this bug is that the fetch throws before dispatch, so your logs show the error with no corresponding outbound request. After the fix, you should see the request leave and a real status come back. Expected outcome: provider request count goes from 0 to 1 on the previously failing path.

When to use

Use this when a Cloudflare Worker throws Invalid redirect value on a fetch() call, when an SDK works on Node but fails on Workers with a TypeError before any network I/O, or when you are hardening server-side fetch against open redirects and want the portable equivalent of redirect: "error".

When not to use

Not for 4xx or 5xx responses returned by the server (the request went out fine), not for CORS failures, not for redirect loops (those are a "follow" problem), and not for Response.redirect() throwing on a bad URL, which is a different error about the Location value, not the redirect mode.

Tool and version compatibility

Cloudflare Workers / workerd, all versions: redirect: "error" was never implemented and never will be, per the runtime's own message. Node.js 18+ (undici): accepts all three modes, which is why this bug hides from Node-based tests. Applies to any library that sets the mode, regardless of version.

Variant phrasings

• Invalid redirect value, must be one of "follow" or "manual" (short form, same error)
• TypeError: Invalid redirect value (what logs show when the message is truncated)
• redirect: "error" is unsupported on Cloudflare Workers (how issues usually title it)

Root cause, after the fix

The Fetch spec defines three redirect modes, but workerd deliberately implements only two: at the edge, automatically erroring on a redirect adds no value over returning the 3xx and letting the caller decide, so the runtime rejects the mode at the call site with a synchronous TypeError. Libraries written against Node assume all three modes exist. The mismatch only surfaces in production because Node accepts the value, so the failure looks like a network or provider outage (zero requests sent) when it is really a bad option object.

Edge cases

• The throw happens synchronously inside fetch(), before dispatch. Retry loops (the Slack SDK retries transport failures five times) will burn all retries on the same TypeError; fixing the mode is the only fix, not more retries.
• With "manual", a cross-origin redirect returns the 3xx response to you; your explicit status check is what enforces the no-follow policy, so do not skip step 2.
• Some SDKs capture globalThis.fetch and call it with the wrong receiver on Workers (Illegal invocation); if you see that alongside this error, bind the receiver in the same adapter.
• Response.redirect(url, status) throwing is a different failure (invalid Location URL). If your stack shows both, fix the redirect mode first, then validate the URL being redirected to.

In gh:better-auth/better-auth#10052: @better-auth/sso v1.6.16+ sets redirect: 'error' in OIDC discovery fetch; workerd throws and SSO sign-in returns 502. In gh:textqllabs/textql-ts-sdk (commit bcbb8a9): connect-web sets redirect: 'error' on every fetch, so streaming RPCs fail on Workers while unary succeed; fixed by normalizing to 'manual' in the transport. In gh:tarkovtracker-org/TarkovTracker#653: getActiveSeasonNumber passed redirect: 'error'; workerd rejects at the call before dispatch; fixed with 'manual'. In gh:cortech-online/dmarcheck (commit 3c6ef5e): the same regression slipped past Node unit tests twice because undici accepts the option; guarded with a @cloudflare/vitest-pool-workers smoke test.