A Server Action that revalidatePaths its own route + returns a value can leave the appended RSC segment never draining (useActionState hangs) — strong production evidence, help finding the co-factor

[gettoss90]

Next.js 16.2.10 · React 19.2.7 · App Router

We have a reproducible-in-production, intermittent deadlock and a lot of evidence isolating it, but a clean-room minimal app does not yet trigger it — so we're posting this as a discussion to ask where in the App Router / Flight pipeline the failure could live, and which environmental co-factor to instrument next. Full evidence and a minimal harness below; happy to share the harness repo and raw captures.

What we observe

A Server Action that calls revalidatePath(currentRoute) and then returns a value (rather than redirect()-ing) makes Next append the freshly re-rendered RSC segment of the current route to that action's own POST flight response, after the 1:{…} action-return row. When that appended segment is large (≳800 KB), it intermittently never drains/closes: the HTTP response stays open, so the client's useActionState promise never settles and the form is stuck pending forever. The page render always completes — only the post-render flush of the appended segment hangs.

Production stack where we see it: output: 'standalone' server under PM2 cluster mode, behind nginx (proxy_buffering on, proxy_cache), behind the Cloudflare proxy (HTTP/2 to the browser). Route is force-dynamic; action bound via useActionState.

Production evidence

1. The discriminator — HAR body size + whether the response ever finished

Same route, same fixture, same worker pool; three identical fires of the action:

Fire	action POST	response finished?	HAR contentSize / bodySize	outcome
1	200 text/x-component	resolved @843 ms	872,404 / 281,399	✅ completed
2	200 text/x-component	never (40 s)	−1 / −1	❌ stalled
3	200 text/x-component	never (40 s)	−1 / −1	❌ stalled
control	200 text/x-component	resolved @1 ms	99 bytes (…1:{"ok":true})	✅ (no revalidatePath)

2 of 3 identical fires stalled; 1 streamed the full 872 KB. The only variable is timing ⇒ a race, not a deterministic path. The control fire (same action shape minus revalidatePath) closes in ~1 ms / 99 bytes — isolating revalidatePath-into-return as the trigger.

2. The render always completes (rules out the app's own await graph)

Server-side render spans for each fire (the re-render triggered by revalidatePath), same worker, immediately after the action-return:

Fire	action-return logged	render phases	render-return
1 (completed)	✅	all	✅ @199 ms
2 (stalled)	✅	all	✅ @652 ms
3 (stalled)	✅	all	✅ @374 ms

Both stalled fires logged render-return — the page component ran to completion (sub-second) before the stream hung. The hang is in the framework's post-render flush of the appended segment, not in the render or our data layer.

3. The DB is idle during the hang

pg_stat_activity sampled ~15 s into each stalled fire's pending window: 0 active (non-idle) backends — every pooled connection idle. No query is in flight while the stream hangs, so the wait isn't in our data access.

4. Size sensitivity

The same revalidatePath(currentRoute) + return {ok:true} shape on a ~647 KB route completed 2/2 (never stalled); the ~872 KB route lost the flush race ~2/3 of the time. The failing cell is (large revalidated RSC segment) × (appended to a Server Action's own POST response), and it is size/latency-sensitive.

Minimal shape

// app/actions.ts
'use server'
export async function revalidateAction(prev, formData) {
  revalidatePath('/')                       // revalidate this action's OWN route
  return { ok: true, ranAt: Date.now() }    // …then RETURN (do not redirect)
}

// app/page.tsx
export const dynamic = 'force-dynamic'
// renders ~9k–20k text rows → ~1.3 MB–3 MB revalidated RSC segment

// app/Forms.tsx
'use client'
// useActionState form; status = PENDING until the action settles

Fire revalidateAction repeatedly (real click, browser fetch, or a raw POST to the page path with the Next-Action header) and watch whether the ~1.3 MB+ response drains and the form settles.

Clean-room reproduction status — the shape alone did not reproduce it

On a bare Next 16.2.10 app we could not reproduce the deadlock across 379 fires, spanning every transport/runtime/proxy combination we could think of:

config	runtime	transport	client	payload	fires	stalled
curl / Node, sequential + concurrent, slow readers	next start	HTTP/1.1	curl, Node	1.32 MB	78	0
browser fetch + real useActionState click	next start	HTTP/1.1	Chromium	1.32 MB	24	0
concurrent slow readers	standalone	HTTP/1.1	Node	2.97 MB	64	0
concurrent slow readers, behind an nginx-style buffering proxy	standalone	HTTP/1.1	Node	2.97 MB	80	0
browser fetch + click, async (awaited) render	standalone	HTTP/1.1	Chromium	2.97 MB	37	0
concurrent slow readers, HTTP/2 (h2c) flow control	standalone	HTTP/2	Node http2	2.97 MB	96	0
total					379	0

Every configuration — including write-backpressure (deliberately slow readers), concurrency, a buffering reverse proxy, HTTP/2 flow control, and an async/awaited render — drained the full ~1.3–3 MB appended segment and closed cleanly. So the shape+size looks necessary but not sufficient: the production deadlock has an additional environmental co-factor absent from the minimal surface.

Leading co-factor candidates (in order)

1. Cloudflare-edge HTTP/2 flow control against the origin — our h2c test used a local Node http2 proxy, not the real edge window/settings.
2. PM2 cluster mode — multiple worker processes; a flush deadlock tied to cluster socket handoff or per-worker cache-invalidation timing.
3. nginx proxy_buffering disk-spill at the configured proxy_buffers / proxy_max_temp_file_size thresholds (a local pass-through proxy doesn't spill to disk).
4. The exact app await-graph / middleware (an AsyncLocalStorage request context, etc.) subtly changing the flush timing.

Workaround (shipped, reliable)

For any Server Action that would revalidatePath(currentRoute) and then return a value: drop the in-action revalidate and instead return the result and call router.refresh() on the client after the action settles. redirect() after revalidatePath is also safe (the redirect supersedes the appended segment). Only the revalidatePath(currentRoute) + return value shape on a large route is affected.

What we're asking

1. Where in the App Router / Flight pipeline is the revalidated route segment appended to a Server Action's POST response, and under what backpressure / flow-control condition could that appended segment's flush fail to close the stream?
2. Is the post-render flush of the appended segment expected to be robust to a slow or flow-control-limited consumer, or could a specific edge/proxy/cluster interaction deadlock it?
3. Which of the four co-factors above would you instrument first? Guidance there would let us build a self-contained repro to hand over.

Happy to share the full minimal harness (repro app + the probe scripts behind the 379-fire table) and the raw production captures (HAR files, server render-span logs, pg_stat_activity snapshots) if useful.

[MentalOfCrow]

Your interpretation of the response shape matches the 16.2.10 source. The action and refreshed route are not two independent HTTP responses that happen to be concatenated; they become two fields in the same RSC payload/stream.

The relevant path is:

1. executeActionAndPrepareForRender runs the action. A path revalidation leaves skipPageRendering false and switches the request into the render phase.
2. The fetch-action path then calls generateFlight with both actionResult and skipPageRendering (lines 1143–1183).
3. generateDynamicRSCPayload builds the fresh flightData when rendering is not skipped and returns one payload containing { a: actionResult, f: flightData, ... }.

That explains why seeing the action-return row does not imply that useActionState can settle independently: the client is still consuming the same Flight response and references in a/f may not be usable until the stream progresses.

Given your 379 clean-room passes, I would not change the harness again yet. I would run the real production build, route, fixture and action through a layer-removal matrix. It gives a stronger answer than adding more synthetic flow-control cases:

Test	Path	What it removes
A	Browser → Cloudflare → nginx → PM2 cluster	baseline
B	Browser/curl → nginx origin → PM2 cluster	Cloudflare
C	localhost/SSH tunnel → PM2 port	Cloudflare + nginx
D	localhost → one PM2 worker (instances: 1)	cluster scheduling
E	localhost → node .next/standalone/server.js	PM2 entirely

For B, preserve the production hostname/SNI/cookies rather than changing the URL. For example, use curl --resolve app.example.com:443:ORIGIN_IP ... or a temporary hosts entry. Changing the host can change middleware, action origin validation and cache keys.

I would add a temporary nginx access-log format that records at least:

log_format flight '$request_id $status rt=$request_time '
                  'urt=$upstream_response_time uaddr=$upstream_addr '
                  'ubs=$upstream_bytes_received bs=$body_bytes_sent '
                  'conn=$connection creq=$connection_requests';

After aborting a stalled request, the useful discriminator is:

• upstream_response_time completes and upstream_bytes_received is ~872 KB, but the client did not finish: the origin completed; investigate nginx downstream buffering or Cloudflare.
• upstream_bytes_received stops short and the upstream stays open: the block is at/before the Node response, or nginx is applying backpressure to it.
• C succeeds while B stalls: nginx is the first failing layer.
• D succeeds while C stalls: cluster mode is the first failing layer.

For one diagnostic route/location, test the response path without nginx's three moving parts:

proxy_http_version 1.1;
proxy_buffering off;
proxy_cache off;
gzip off;

proxy_request_buffering is not the interesting switch here; your evidence concerns the response after the action and render have completed. If proxy_buffering off fixes it, split the controls afterward: buffering on with temp-file writes disabled/raised, then compression, then cache. That will tell you whether the threshold is memory-buffer → temp-file spill rather than Flight size itself.

I would test Cloudflare second, not first. First establish whether nginx received the complete upstream response. If nginx received all bytes, repeat A with a cache-bypass rule and response transformations/compression disabled for the affected route. Also confirm the actual Cloudflare-to-origin protocol; browser HTTP/2 does not prove the origin leg is HTTP/2.

Finally, log the PM2 worker PID on every action start, action return and render return. If a stalled response always belongs to one PID, drain that worker and compare its open handles/socket state. If it moves randomly and disappears at instances: 1, the cluster layer becomes a reproducible co-factor rather than a theory.

So my first experiment would be C versus B on the exact production app, with the nginx upstream-byte timings enabled. It is the shortest test that distinguishes framework/PM2 from proxy buffering, and it does not require modifying Next internals. Your router.refresh() workaround is sensible because it deliberately separates the small action response from the later Flight request.

If this isolation matrix identifies the failing layer, please mark this as the accepted answer; the resulting nginx/PM2/Cloudflare discriminator will also make a much stronger upstream bug report.

[ISMEG-0x00]

Why this happens (RSC Flight Stream Deadlock)
When a Server Action calls revalidatePath and returns a value, Next.js performs two tasks in a single HTTP stream:

Emits the action's return tuple (e.g., 1:{"ok":true}) immediately.

Re-renders the current route, serializing the newly rendered RSC segment directly into the same streaming response via React Server Components (Flight) stream.

The post-render flush hangs when backpressure from downstream proxies (Cloudflare/Nginx) causes Node's underlying WritableStream to fill its high-water mark buffer while React's server renderer is waiting for a stream drain event that never fires or gets swallowed.

Which co-factor to instrument first
Start with Co-factor 1 (Cloudflare HTTP/2 Flow Control) & Co-factor 3 (Nginx Disk-Spill Buffering):

Nginx proxy_max_temp_file_size: When an RSC response exceeds Nginx's in-memory buffers (proxy_buffers), Nginx attempts to buffer the remaining stream to a temporary file on disk. If proxy_buffering is enabled and proxy_max_temp_file_size is reached or throttled by Cloudflare's HTTP/2 window updates, Node's stream socket pauses emitting data.

React 19 Stream Drain Listener: Under high backpressure, Node's res.write() returns false (signaling buffer full). React 19 waits for the 'drain' event to continue enqueuing chunks. If Cloudflare/Nginx closes or halts the HTTP window update without closing the TCP connection, the 'drain' event never fires on Node's socket, leaving the HTTP response permanently pending.

Recommended Debugging / Next Steps
To isolate and build a minimal reproduction for the Next.js core team:

Bypass Cloudflare temporarily: Test the endpoint directly against your Nginx / PM2 setup. If it stops stalling, the issue is directly tied to Cloudflare's edge-to-origin HTTP/2 multiplexing window size limit (initial_window_size).

Disable Nginx Disk Buffering on RSC endpoints: Add proxy_max_temp_file_size 0; to your Nginx configuration for Next.js Flight responses (Header match Content-Type: text/x-component) to see if preventing disk spill resolves the flush deadlock.

Instrument the Response Stream: Add a lightweight wrapper around res.write in custom middleware/server to log when res.write() returns false and whether the subsequent drain event is ever emitted during the stall.

Note: Your client-side workaround (router.refresh() post-action or redirect()) remains the safest production strategy for large RSC segments until the upstream Flight stream backpressure handling is patched in next/server.

[MentalOfCrow]

@ISMEG-ZAKARIA

Thanks — the backpressure explanation is plausible, but I think it is too early to present it as the confirmed root cause.

The current evidence confirms that:

• the Server Action returns;
• the re-render triggered by revalidatePath() completes;
• the database is idle during the stalled window;
• the combined Flight response sometimes remains open;
• the failure becomes more likely as the appended RSC payload grows.

However, it does not yet prove that:

• res.write() returned false;
• React started waiting for a drain event;
• that drain event was lost or swallowed;
• Cloudflare stopped issuing HTTP/2 window updates;
• nginx reached a temporary-file threshold.

Those are useful hypotheses to test, but they should remain hypotheses until the failing layer is isolated.

Important nginx distinction

These two directives test different things:

proxy_buffering off;

This disables nginx response buffering for the location.

proxy_max_temp_file_size 0;

This only prevents buffered responses from being written to temporary files. It does not disable the in-memory buffering controlled by directives such as:

proxy_buffer_size
proxy_buffers
proxy_busy_buffers_size

Therefore, the following tests should be run independently:

Test | proxy_buffering | proxy_max_temp_file_size | What it isolates -- | -- | -- | -- Baseline | on | Current production value | Existing production behavior Memory-only buffering | on | 0 | Temporary-file spill No response buffering | off | Irrelevant | nginx buffering and downstream backpressure as a whole

Recommended isolation matrix

I would test the exact production build, route, fixture and action through this matrix:

A. Browser -> Cloudflare -> nginx -> PM2 cluster
B. Browser/curl -> nginx origin -> PM2 cluster
C. localhost or SSH tunnel -> PM2 port
D. localhost -> PM2 with instances: 1
E. localhost -> .next/standalone/server.js without PM2

For test B, preserve the production hostname, cookies and TLS/SNI behavior. For example:

curl --resolve app.example.com:443:ORIGIN_IP \
  https://app.example.com/affected-route \
  -H 'Next-Action: ACTION_ID'

Changing the hostname may also change middleware behavior, action-origin validation, cache keys or application routing.

Cloudflare testing

Cloudflare HTTP/2 flow control is worth testing, but only after determining whether nginx received the complete upstream response.

The browser using HTTP/2 does not prove that the Cloudflare-to-origin connection also uses HTTP/2. The actual origin protocol and zone configuration should be verified directly.

If nginx receives the full upstream response, compare:

Cloudflare enabled
    |
    v
Cache bypassed
    |
    v
Response transformations disabled
    |
    v
Compression disabled
    |
    v
HTTP/2 to origin disabled temporarily

If bypassing Cloudflare fixes the issue while the exact same nginx and PM2 path remains stable, Cloudflare becomes the first demonstrated failing layer.

About instrumenting res.write()

Instrumenting res.write() would provide strong evidence, but standard Next.js middleware does not expose the raw Node ServerResponse.

A reliable wrapper would require one of the following:

• a temporary custom Node server around the Next request handler;
• instrumentation inside the generated standalone server;
• a temporary patch around the Next.js response writer;
• framework-level instrumentation at the point where the Flight stream is piped to the HTTP response.

The relevant signals would be:

res.write(chunk) -> true
    Continue writing
res.write(chunk) -> false

Start waiting for drain
drain emitted

Resume writing
close emitted before drain

Downstream connection closed
Neither drain nor close emitted

Writable remains blocked

Until those signals are captured during an actual stalled request, the missing-drain explanation should not be treated as confirmed.

Suggested order of experiments

1. Enable nginx upstream-byte and timing logs.
2. Compare direct PM2 access with access through nginx.
3. Test proxy_buffering off.
4. Test proxy_buffering on with proxy_max_temp_file_size 0.
5. Repeat with PM2 instances: 1.
6. Bypass Cloudflare while preserving the production hostname and cookies.
7. Only then instrument the raw Node response stream if the stall remains on the direct PM2 path.

The router.refresh() workaround remains sensible because it separates the small Server Action response from the later Flight request. However, the fact that this workaround succeeds does not by itself prove that the underlying cause is a missing Node drain event.

[barriosmemoria23-collab]

Additional evidence from a different application: the redirect variant can stall too, without nginx, Cloudflare, or PM2 in the path.

Environment:

• Next.js 16.2.11, React/React DOM 19.2.4
• production standalone build on GitHub Actions Linux, Node 20
• Chromium 147 against localhost over HTTP/1.1
• real Next server and browser; the domain API is an HTTP fixture

Action shape:

1. await an upstream mutation
2. revalidatePath(the current route)
3. redirect(the same route plus a flash-message query)

One of two comparable CI executions stalled. The same targeted flow and its actual predecessors completed in all 62 controlled local attempts. I am reporting those rates separately rather than calling this flaky: CI 1/2 stalled; local 0/62 stalled.

Sanitized Playwright trace entry for the action POST at artifact closure:

status: 303 See Other
content-type: text/x-component
transfer-encoding: chunked
x-action-redirect: /same-route?...;push
x-action-revalidated: 1
content.size: -1
bodySize: -1
_transferSize: -1
wait: 99.016 ms
receive: 31.808 ms

The 303 headers arrived and Playwright observed the response, but five seconds later:

• the browser URL was still the original URL;
• useFormStatus().pending was still true;
• the redirect target UI and flash message were absent;
• there was no React Routing questions - params patterns like: "/profile/:id/edit" and server db -how to pass data to react components? #418, hydration error, pageError, or console error.

The mutation definitely completed before the stall: the x-action-redirect message contains a calculated value read from the upstream mutation response, so the action could not have constructed that header before consuming the successful upstream result.

This seems to narrow the stuck boundary to the Flight body used to commit the app-relative redirect. In the Next action handler this path internally fetches the redirect target as RSC and returns its response body as FlightRenderResult. The trace had bodySize=-1 and transferSize=-1 for that POST when the test artifact closed.

We also checked two plausible application-side races:

• the session-activity POST overlapped the click in the failed trace, but deliberately delaying that response from 0 to 1,000 ms produced 30/30 clean runs;
• Link prefetch RSC GETs occur after revalidation, but they are separate requests and no application code reads the action response body a second time.

This extends the original report in two useful ways: redirect() does not always supersede the problematic Flight path, and the failure reproduced on a direct standalone localhost path without the proxy/cluster topology from the original report.

Our product mitigation is a truthful 15-second uncertain-result state plus a verification link, backed by an idempotent mutation so retry cannot duplicate the operation. That contains user risk but does not fix the stream.

The most useful next instrumentation point appears to be between the internal redirect-target RSC fetch / FlightRenderResult body and the client router commit. Is there an existing debug hook or trace point in 16.2.x that can distinguish an origin body that never closes from a body that closes but is never committed by the client reducer?