Modal made with parallel & intercepted routes, and revalidation in server action throws an error

[roksui]

Summary

What am I trying to do?

I am trying to leverage the power of parallel & intercepted routes to create a modal and inside of that modal, fetch data on the server side and also allow users to mutate the data and be shown fresh up-to-date data all within one opening of the modal.

To test the feasibility of this functionality I modified Nextagram such that each modal displays a list of comments and a button for adding a new comment. For the simplicity of testing, I made an external mock API for fetching and mutating comments in the intercepted route only for the first modal (/photos/1).

Clicking on the button creates a new comment by invoking a server action. Inside the server action, revalidateTag is called, so the comments displayed in the modal are updated after the mutation is finished.

However, this didn't go well and there is a couple of observations I have made.

Observation 1

On the first button click, the page underneath the modal that shows the photo cards turns blank. I assume this happens because revalidateTag makes the Next server lose the active state of the page, so it uses default.tsx to render it, which in this case just returns null.

Related issue

#60815

Observation 2

After opening the modal and clicking on the button to add a comment, it works for the first two clicks - comments are successfully added and the list of comments is updated. However, on the third click, it fails with the following error in the Next.js server. (Reopening the modal repeats this process)

Error: Failed to find Server Action "f81668b9813c4972f14d4e2df1b61f5d9531853a". This request might be from an older or newer deployment. Original error: Invariant: Couldn't find action module ID from module map.
    at rn (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:39:1697)
    at D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:38:7364
    at AsyncLocalStorage.run (node:async_hooks:338:14)
    at rr (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:38:6672)
    at rM (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:40:1408)
    at D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:40:3179
    at AsyncLocalStorage.run (node:async_hooks:338:14)
    at Object.wrap (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:36:16261)
    at D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:40:3067
    at AsyncLocalStorage.run (node:async_hooks:338:14)
    at Object.wrap (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:36:15459)
    at rF (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:40:2994)
    at r2.render (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:40:7090)
    at doRender (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\server\base-server.js:1416:44)
    at cacheEntry.responseCache.get.routeKind (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\server\base-server.js:1565:46)
    at ResponseCache.get (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\server\response-cache\index.js:49:26)
    at DevServer.renderToResponseWithComponentsImpl (D:\Dev\playgrounds\my-nextagram\my-nextagram\node_modules\next\dist\server\base-server.js:1485:53) 

After investigating a bit, I found that this error is caused because the third button click sends a request which does not have the Next-Url header set, whereas the first two clicks do. In fact, the first click and second click send different Next-Url values - /children and / respectively. I assume that this difference in the Next-Url header is caused because of revalidateTag changing the React component tree on the client side for the / route due to the reason described in observation 1.

Related issue

#58431

Question

I expected that because the fetching is done using Next's fetch with the tags property set in the page.tsx of the intercepted route, the other parallel route, namely the / route should not be affected by the revalidation. Am I misunderstanding something or is this observation the intended behavior? If so, what should be done so that this page does not change its state even with the revalidation in the server action invoked from the modal?

Additional information

- Tested with `14.1.1-canary.54`
- Node version used: 18.17.1
- Run with `npm run dev` in development mode.

Example

https://github.com/roksui/my-nextagram.git

[sim391calado]

I was about to open an issue on exactly this. Also for me, the folder structure on the app router seems to affect the observation 1. In some cases, if I don't have the @modal/(.)post/[id]/page.tsx in the same route folder as the actual /post/[id/page.tsx, I get a complete redirect to the actual post page, instead of keeping in the modal page view, after the 3rd click on the server action. I have to investigate further.

[stefan-joseph]

I am also experiencing this error after the third server action is sent within an intercepting route modal. Thus, closing the modal and redirecting the user to the actual route where the intercepting route points.

[stefan-joseph]

In the headers for attempts one and two I get "/children/children" and "/" respectively for next-url. In the third attempt when the error takes place, next-url is missing.

[stefan-joseph]

Yes, it seems that revalidateTag and revalidatePath are causing this error. When removed from the server action, the error does not occur on the third server action attempt or any others thereafter.

[roksui]

@sim391calado @stefan-joseph I just confirmed that observation 2 with revalidating in the intercepted route has been fixed by #63263.

[roksui]

Observation 1 is fixed in v14.2.0-canary.47.

[eduardodallmann]

Reference #58431 (comment)

[eduardodallmann]

Problems with server actions not found when navigating actually stopped in version 14.2
But revalidate still doesn't happen when navigating. Is this related to caching?

https://codesandbox.io/p/github/eduardodallmann/app-next-server-action-problem-2/