Fix server action forwarding loop with middleware rewrites#93792
Merged
Conversation
Avoid infinite peer-forward loops when middleware rewrites paths or the request was already forwarded (x-action-forwarded). The receiving worker short-circuits the forwarding decision and falls through to lenient serverModuleMap resolution instead of forwarding again. Adds a self-contained e2e regression test that reproduces the loop via a proxy.ts rewrite: with the fix the request resolves in ~150ms; without the fix it hangs until the test's 10s abort timer fires. Fixes #84504 Supersedes #84525, #92053
Contributor
|
Thanks so much for picking this up unstubbable! Really appreciate it! 🙏 |
Contributor
Tests PassedCommit: fe62eb3 |
Contributor
|
@lubieowoce would you be able to review this please? I'm sorry to bother you but this is causing issues for us in prod and we had to patch next to fix it. Hoping we can get this merged so we have a clear upgrade path. If you're planning to review later that's fine too and please ignore me :) Either way thank you all kindly and keep up all your great work! 🙏 |
lubieowoce
approved these changes
May 14, 2026
Contributor
|
@unstubbable I know I'm pushing it but any chance this could land in a v16.2.x patch release? We're carrying a bun patch in prod against |
unstubbable
added a commit
that referenced
this pull request
May 18, 2026
Reopens #93710 from a branch on this repo so the required deploy test matrix can run — GitHub Actions doesn't expose secrets to fork PRs, and those deploy jobs are required checks. All commits and credit carry forward from the original PR by @elishagreenwald, which built on earlier attempts by @LiamBoz in #84525 and @claygeo in #92053. When middleware rewrites a Server Action POST to a page that doesn't bundle the action, the receiving worker forwards the request to a worker that does. The forwarded request hits middleware again and gets rewritten the same way, so the new receiving worker forwards again — looping until undici's headers timeout (~300s) or memory pressure brings the server down (#84504). The fix is two related changes on the forwarding code path. The first is an `!actionWasForwarded` guard in `action-handler.ts` so a request carrying `x-action-forwarded: 1` is never forwarded a second time. The second is a new branch in `createForwardedActionResponse` that copies the `x-nextjs-action-not-found` header and 404 status onto the originating response when the forwarded worker can't find the action either; without it the client would see a generic "unexpected response" error instead of the `UnrecognizedActionError` that the rest of the framework expects. The e2e test at `test/e2e/app-dir/action-forward-loop` reproduces the scenario. A `proxy.ts` rewrites POSTs to `/with-action` so GETs still render the page normally; the page renders a `<form>` with an inline server action wrapped in a React error boundary that branches on `unstable_isUnrecognizedActionError`. The test clicks the button and waits for `#action-not-found-error`. Without the loop guard the test times out at 10s, and without the pass-through the boundary catches a generic error and the assertion fails — so both changes are individually load-bearing. This is a short-term fix. The mid-term direction is to remove server-side action forwarding altogether and have the client dispatch each Server Action to the route that actually bundles it, which makes the entire forwarding code path (and this bug surface) unnecessary. #90549 is the draft exploring that approach. Fixes #84504 Closes #93710 Closes #84525 Closes #92053 --------- Co-Authored-By: Elisha Greenwald <ejgreenwald@gmail.com> Co-Authored-By: LiamBoz <thisamazingnow@gmail.com> Co-Authored-By: kmaclip <kmartclips@proton.me>
Contributor
Author
|
@elishagreenwald We'll include the fix in the next patch release. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reopens #93710 from a branch on this repo so the required deploy test matrix can run — GitHub Actions doesn't expose secrets to fork PRs, and those deploy jobs are required checks. All commits and credit carry forward from the original PR by @elishagreenwald, which built on earlier attempts by @LiamBoz in #84525 and @claygeo in #92053.
When middleware rewrites a Server Action POST to a page that doesn't bundle the action, the receiving worker forwards the request to a worker that does. The forwarded request hits middleware again and gets rewritten the same way, so the new receiving worker forwards again — looping until undici's headers timeout (~300s) or memory pressure brings the server down (#84504). The fix is two related changes on the forwarding code path. The first is an
!actionWasForwardedguard inaction-handler.tsso a request carryingx-action-forwarded: 1is never forwarded a second time. The second is a new branch increateForwardedActionResponsethat copies thex-nextjs-action-not-foundheader and 404 status onto the originating response when the forwarded worker can't find the action either; without it the client would see a generic "unexpected response" error instead of theUnrecognizedActionErrorthat the rest of the framework expects.The e2e test at
test/e2e/app-dir/action-forward-loopreproduces the scenario. Aproxy.tsrewrites POSTs to/with-actionso GETs still render the page normally; the page renders a<form>with an inline server action wrapped in a React error boundary that branches onunstable_isUnrecognizedActionError. The test clicks the button and waits for#action-not-found-error. Without the loop guard the test times out at 10s, and without the pass-through the boundary catches a generic error and the assertion fails — so both changes are individually load-bearing.This is a short-term fix. The mid-term direction is to remove server-side action forwarding altogether and have the client dispatch each Server Action to the route that actually bundles it, which makes the entire forwarding code path (and this bug surface) unnecessary. #90549 is the draft exploring that approach.
Fixes #84504
Closes #93710
Closes #84525
Closes #92053