fix: server actions should fetch from the router canonicalUrl #80690
Conversation
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
ztanner
commented
Jun 19, 2025
| @@ -898,13 +898,6 @@ describe('app-dir action handling', () => { | |||
| .elementByCss(`[href='/delayed-action/${runtime}/other']`) | |||
| .click() | |||
|
|
|||
| // wait for url to change | |||
There was a problem hiding this comment.
this was added in 5d4f2de to attempt to de-flake the test but shouldn't be necessary. I also needed to touch this file so that flake detection will run
unstubbable
approved these changes
Jun 19, 2025
lubieowoce
approved these changes
Jun 19, 2025
ztanner
deleted the
06-19-fix_server_actions_should_fetch_from_the_router_canonicalurl
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A test related to navigation + server action handling was frequently flaking in CI (x-ref). When simulating a 20x browser slowdown, it's fairly easy to reproduce the failure case as well.
The failure occurs due to a race where the router will invoke the server action against the page the user was on before the navigation, but after the navigation action has been processed. As a result, the RSC payload associated with the target page gets replaced by the RSC payload returned from the server action. There exists a window of time where
window.location.pathnameis still referring to the previous URL whilerouterState.canonicalUrlwould have been updated to the new page.This revealed two things: