fix: prevent useActionState state becoming undefined when redirect() is called (#589)

[yunus25jmi1]

Description

This PR fixes issue #589 where useActionState receives undefined state when a Server Action calls redirect() from next/navigation, causing a TypeError on the next render.

---

Problem

When a server action used with useActionState calls redirect():

1. The server catches the redirect error and returns redirect headers
2. Problem: Server was sending empty response body
3. Client's RSC navigation expects a valid RSC payload but receives empty body
4. Navigation fails silently, leaving useActionState with undefined state
5. TypeError on next render when accessing state properties

Example:

'use client';
import { useActionState } from 'react';
import { redirect } from 'next/navigation';

async function createPost(_prev: ActionResult, formData: FormData): Promise<ActionResult> {
  // ... create post logic ...
  redirect(`/posts/${postId}`); // <-- triggers the bug
}

export function PostForm() {
  const [state, formAction, pending] = useActionState(createPost, { success: false, error: '' });

  // TypeError: Cannot read properties of undefined (reading 'success')
  return (
    <form action={formAction}>
      {!state.success && state.error && <p>{state.error}</p>}
      <button type="submit">Submit</button>
    </form>
  );
}

---

Root Cause

Server action redirects were sending empty response body with only headers:

// Before: empty body
return new Response("", { status: 200, headers: redirectHeaders });

RSC navigation requires a valid RSC payload to parse and render. Empty body causes navigation to fail.

---

Solution

Pre-render the redirect target's RSC payload on the server and include it in the response body. This matches Next.js behavior where the redirect response includes the target page's RSC payload for soft SPA navigation.

Server-side (app-rsc-entry.ts)

// After: render redirect target's RSC payload
const redirectMatch = matchRoute(redirectPathname);
if (redirectMatch) {
  const redirectElement = buildPageElement(redirectRoute, redirectParams, ...);
  const rscStream = renderToReadableStream({ root: redirectElement, ... });
  return new Response(rscStream, { status: 200, headers: redirectHeaders });
}

Client-side (app-browser-entry.ts)

// Check if response has RSC payload
const hasRscPayload = contentType.includes('text/x-component') && fetchResponse.body;

if (hasRscPayload) {
  // Soft RSC navigation (SPA-like)
  const result = await createFromFetch(Promise.resolve(fetchResponse), ...);
  getReactRoot().render(result.root);
} else {
  // Fallback: hard redirect for empty body
  window.location.assign/replace(actionRedirect);
}

---

Benefits

1. ✅ Fixes issue useActionState receives undefined state when Server Action calls redirect() #589 - useActionState no longer receives undefined state
2. ✅ Preserves SPA navigation - Soft RSC navigation instead of hard page load
3. ✅ Matches Next.js parity - Pre-renders redirect target like Next.js does
4. ✅ Backward compatible - Falls back to hard redirect if payload unavailable

---

Changes

Core Fix

• packages/vinext/src/entries/app-rsc-entry.ts: Pre-render redirect target's RSC payload
• packages/vinext/src/server/app-browser-entry.ts: Use RSC navigation when payload available, fallback to hard redirect

Test Coverage

• tests/fixtures/app-basic/app/actions/actions.ts: Added redirectWithActionState test action
• tests/fixtures/app-basic/app/action-state-redirect/page.tsx: Added test page
• tests/e2e/app-router/server-actions.spec.ts: Added E2E test for issue useActionState receives undefined state when Server Action calls redirect() #589 with waitForHydration

---

Testing

• ✅ Shims test: 730 tests passed
• ✅ Entry templates snapshot updated
• ✅ E2E test added for the fix

---

Related Issues

• Fixes useActionState receives undefined state when Server Action calls redirect() #589

---

Signed-off-by: Md Yunus admin@yunuscollege.eu.org

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@620

commit: 84a845c

[yunus25jmi1]

@southpolesteve The PR is in a clean state for merge. Kindly review the PR and merge it.

[southpolesteve]

/bigbonk review

[ask-bonk]

Review Summary

The core fix (using hard navigation for action redirects) is a reasonable workaround given that vinext's server sends an empty body for redirect responses. However, there are several issues: dead code left behind, a misleading standalone test file, and a missing waitForHydration call.

How Next.js actually handles this

For context: Next.js does not always hard-redirect on action redirects. For internal redirects, Next.js pre-renders the RSC payload of the redirect target and includes it in the response body, then applies it as a soft SPA navigation on the client (navigateToKnownRoute). Hard navigation (location.assign/location.replace) is the fallback when no flight data is available.

The real root cause is that vinext's server sends an empty body (new Response("", ...) in app-rsc-entry.ts:2060) for redirect responses, so RSC navigation has nothing to parse. The hard redirect approach works as a stopgap, but it regresses non-useActionState action redirects that previously used soft navigation. This should be documented as a known parity gap.

Issues to address

1. Dead code: history.pushState/replaceState calls (lines 148-152) are now useless since window.location.href immediately triggers a full page load. Should use location.assign()/location.replace() instead to preserve push/replace semantics (matching Next.js's completeHardNavigation).

2. Misleading comment: The comment says RSC navigation doesn't work "with useActionState" but this change affects all action redirects.

3. tests/repro-589.spec.ts should be removed: It hardcodes port 3000 (no Playwright project uses this), duplicates the E2E test, and has a stale comment describing a different fix.

4. Missing waitForHydration in the E2E test.

See inline comments for details.

[ask-bonk]

Two issues here:

1. Dead code above: The history.pushState/replaceState calls at lines 148-152 (unchanged, not in this diff hunk) are now dead code. window.location.href performs a full page load which discards the history entry just pushed. You should remove those calls and instead use location.assign() vs location.replace() here to preserve the push/replace distinction — matching what Next.js does in completeHardNavigation:

Suggested change

	// Always use hard redirect for action redirects.
	// RSC navigation doesn't work reliably with useActionState because
	// the response body is empty and React expects a valid RSC payload.
	window.location.href = actionRedirect;
	return undefined;
	// Use hard redirect for all action redirects because vinext's server
	// currently returns an empty body for redirect responses. RSC navigation
	// requires a valid RSC payload. This is a known parity gap with Next.js,
	// which pre-renders the redirect target's RSC payload.
	const redirectType = fetchResponse.headers.get("x-action-redirect-type") ?? "replace";
	if (redirectType === "push") {
	window.location.assign(actionRedirect);
	} else {
	window.location.replace(actionRedirect);
	}

(This suggestion also replaces the redirectType / pushState/replaceState block above it — you'd need to remove lines 147-152 as well.)

2. Misleading comment: The current comment says RSC navigation doesn't work "with useActionState" specifically, but this change affects all server action redirects, not just useActionState. The existing test "server action with redirect() navigates to target page" also hits this path. The comment should reflect that this is a general limitation of the empty-body redirect response.

[ask-bonk]

This file should be removed entirely:

1. Hardcoded port 3000 — No Playwright project in playwright.config.ts uses port 3000, so this test will never be discovered or run in CI.
2. Duplicate — The same test already exists in tests/e2e/app-router/server-actions.spec.ts (lines 174-190) under the app-router project, which is the correct location.
3. Stale comment (lines 9-12) — Says "we throw an error instead of returning undefined" but the actual fix uses window.location.href for hard redirect. This comment describes a different approach that isn't in the PR.

[ask-bonk]

Missing waitForHydration(page) call. Every other test in this file that interacts with client-side JavaScript calls waitForHydration after goto. The useActionState form requires JavaScript hydration to function — clicking the button before hydration completes means the form will do a native submit (full page POST) instead of the client-side server action fetch.

This may pass by accident if hydration completes during the toPass polling, but it should be explicit:

Suggested change

	await page.goto(`${BASE}/action-state-redirect`);
	await page.goto(`${BASE}/action-state-redirect`);
	await expect(page.locator("h1")).toHaveText("useActionState Redirect Test");
	await waitForHydration(page);

[ask-bonk]

The review was submitted successfully. Here's a summary of what I flagged:

Review Posted on PR #620

Verdict: Changes Requested

Key findings:

1. Dead code — The history.pushState/replaceState calls (lines 148-152) are now useless because window.location.href immediately triggers a full page load, discarding any history entry just pushed. Suggested using location.assign() vs location.replace() instead to preserve push/replace semantics, matching Next.js's completeHardNavigation behavior.

2. Misleading comment — The comment claims RSC navigation doesn't work "with useActionState" specifically, but the change affects all server action redirects. This is a regression for non-useActionState action redirects that previously used soft navigation.

3. tests/repro-589.spec.ts should be removed — Hardcodes port 3000 (no Playwright project uses it), duplicates the E2E test already in server-actions.spec.ts, and contains a stale comment describing a different fix approach.

4. Missing waitForHydration — The new E2E test doesn't call waitForHydration(page) after goto, unlike every other test in the file that interacts with client-side JS.

5. Broader context — Noted that Next.js actually pre-renders the redirect target's RSC payload for internal redirects (enabling soft SPA navigation), while vinext sends an empty body. The hard redirect is a valid stopgap but should be documented as a known parity gap.

github run

[yunus25jmi1]

@james-elicx re-review the pr changes.

[james-elicx]

/bigbonk review

[ask-bonk]

All four issues from the previous review have been addressed:

1. Dead code removed — history.pushState/replaceState replaced with location.assign()/location.replace(), correctly preserving push/replace semantics.
2. Comment fixed — Now accurately describes this as a general limitation of the empty-body redirect response, not specific to useActionState.
3. tests/repro-589.spec.ts removed — No stale standalone test file.
4. waitForHydration added — The E2E test properly waits for hydration before interacting with the form.

Minor nit (non-blocking)

The catch block comment at line 144 says "Fall through to client-side navigation if URL parsing fails" but it now falls through to a hard redirect, not client-side navigation. This is cosmetic and doesn't affect correctness.

Overall assessment

The fix is a reasonable stopgap: vinext's server sends an empty body for action redirect responses (app-rsc-entry.ts:2060), so RSC navigation has nothing to parse. Using location.assign()/location.replace() ensures navigation always completes and preserves the push/replace distinction from x-action-redirect-type. The comment clearly documents this as a known parity gap with Next.js (which pre-renders the redirect target's RSC payload for soft navigation).

Test coverage is good — the new E2E test directly exercises the useActionState + redirect() scenario from issue #589, and the existing "server action with redirect() navigates to target page" test validates that non-useActionState redirects also work.

[ask-bonk]

Review submitted. Here's a summary:

Approved PR #620 — The PR addresses all four issues raised in the previous review:

1. Dead history.pushState/replaceState calls replaced with location.assign()/location.replace()
2. Comment now accurately describes the general empty-body limitation, not just useActionState
3. Stale tests/repro-589.spec.ts removed
4. waitForHydration added to the E2E test

The fix itself is a reasonable stopgap: since vinext's server sends an empty body for action redirect responses (app-rsc-entry.ts:2060), RSC navigation has nothing to parse. Hard redirect via location.assign()/location.replace() ensures navigation always completes. The comment properly documents this as a known parity gap with Next.js.

All CI checks pass. One minor non-blocking nit left about a slightly stale catch block comment.

github run

[james-elicx]

I just want to make sure I understand this - are we saying that we're essentially replacing one bug with another?

Can we fix the underlying issue instead?

[yunus25jmi1]

yes, i will look into it.

stale

[yunus25jmi1]

@james-elicx I owe you an explanation and an apology.

The Fix Explained

After researching Next.js documentation and GitHub discussions, I confirmed:

1. Server action redirects return 303 See Other - This is the official Next.js behavior

   • Source: https://nextjs.org/docs/app/api-reference/functions/redirect
   • "When used in a server action, it will serve a 303 HTTP redirect response"

2. Hard redirect is correct for useActionState - Not a workaround

   • Server actions are POST requests
   • 303 triggers POST-Redirect-GET pattern (prevents duplicate submissions)
   • The new page loads with fresh initial state (no undefined issue)

3. This is NOT replacing one bug with another

   • The bug was: empty response body + RSC navigation = failed navigation
   • The fix is: 303 response + hard redirect = successful navigation
   • This matches Next.js spec exactly

My Apology

I force-pushed multiple times during review, which:

• Broke the review context
• Dismissed valid approvals
• Wasted your time

This was unprofessional. I've learned from this and will follow proper PR workflow going forward:

• No force-pushes during review
• Add new commits for changes
• Respond to every review comment

Next Steps

If you approve, I'll squash and merge. If you want changes, I'll add them as new commits (no force-push).

Thanks for your patience.

[yunus25jmi1]

@james-elicx I've identified the issue with my 303 fix - it doesn't work because server actions use fetch(), which doesn't auto-follow redirects.

The Problem

Approach	Why It Fails
303 redirect	fetch() receives 303 but doesn't navigate - page stays stuck
Empty body + RSC nav	No payload to parse - navigation fails

The Fix

Server: Return 200 with x-action-redirect headers (not 303)
Client: Detect header → use window.location.assign/replace() (hard redirect)

// Server (app-rsc-entry.ts)
return new Response(null, { 
  status: 200, 
  headers: { "x-action-redirect": url }  // ← Signal client to navigate
});

// Client (app-browser-entry.ts)  
if (fetchResponse.headers.get("x-action-redirect")) {
  window.location.assign(redirectUrl);  // ← Hard redirect works
}

[james-elicx]

Thanks for looking at it further. I've asked Claude to analyse the behaviour between how Next.js handles redirects and how we will handle redirects with these changes.

It also took a look at the snapshots and what behaviour is happening in those as it seem they're out of sync with the latest changes in the PR.

Below is the table it generated:

Aspect	Next.js	PR Source Code	PR Snapshots
HTTP Status	200	303 ❌	200 ✅
Redirect signal	x-action-redirect header	Location header ❌	x-action-redirect header ✅
Response body	RSC payload of target page	null (empty) ❌	RSC stream ✅
Content-Type	text/x-component	None ❌	text/x-component ✅
Client navigation	Soft SPA via createFromFetch()	Hard window.location ❌	Still uses x-action-redirect headers ⚠️

[yunus25jmi1]

Now, I got some context about the approach. I will work on it.

[yunus25jmi1]

@southpolesteve @james-elicx

First, a sincere apology. This PR became far messier than it should have been. I made multiple attempts to implement full RSC payload streaming to achieve Next.js parity, which was beyond the scope of fixing #589 and introduced regressions that broke previously passing tests. The repeated force-pushes during active review compounded the problem and made the review history difficult to follow. That was unprofessional, and I won't repeat it.

I have reset the branch to commit 46e0f2c, which is the clean, single-commit state that correctly fixes the issue:

• Root cause: server actions called redirect(), the server caught the redirect and returned an empty response body, RSC navigation had nothing to parse, navigation failed silently, and useActionState received undefined on the next render causing a TypeError
• Fix: client detects the x-action-redirect header and performs a hard navigation via location.assign() / location.replace(), preserving push/replace semantics from x-action-redirect-type
• Tests: E2E test added with waitForHydration covering the exact scenario from useActionState receives undefined state when Server Action calls redirect() #589; all existing redirect tests remain green

The full RSC payload streaming approach (pre-rendering the redirect target on the server) is the correct long-term path to Next.js parity, but it is a separate architectural undertaking that should be tracked independently rather than bundled into this bug fix.

CI is green. Ready to merge when you are, and happy to open a follow-up issue for the RSC parity gap if that would be useful.

[southpolesteve]

Fixed the stale catch block comment directly (commit 470fc45 on cloudflare/vinext:fix/issue-589). Also opened #654 to track the RSC parity gap for soft navigation on action redirects. Thanks @yunus25jmi1.

[james-elicx]

Thanks for opening the issue Steve

[yunus25jmi1]

Thank you both, @southpolesteve and @james-elicx, for the thorough review, the patience, and for opening #654 to track the parity gap properly. Looking forward to contributing more.