Calling revalidateTag / revalidatePath in a Server Action breaks the app router once a Parallel slot is rendered

[steve-marmalade]

Summary

I could use help either:

• Building a reproduction
• Sharing ideas on what the root cause could be

@ztanner, this is somewhat of an FYI for you. You've been crushing the Github Issues regarding Parallel + Intercepting routes, and I've been trying to do my part in testing the latest canaries. In general the feature has been much more stable, but I have hit a road block in our closed-source repo that I've been struggling to build a reproduction for. Rather than wait until I can narrow it down, I figured I'd at least start a discussion in case you (or others) have suggestions.

Here's the sequence:

1. Load content in a Parallel Route (in my case, calling router.replace('/path/that/matches/slot', {scroll: false}) to add new content to an existing page as a user scrolls down).
2. Trigger a server action (e.g. click a button)
3. In the server action, call revalidateTag or revalidatePath
4. Notice several issues with the router:
   1. The results of the revalidation are not displayed in the UI
      • I can see the fetch-server-response.ts events in the network tab with what looks like a valid RSC payload, but they aren't displayed
   2. Subsequent navigations to parallel/intercepted routes no longer work (I can see that the event was triggered and the server prepared the RSC, but the URL never changes and the slot is never loaded)
   3. Subsequent navigations to regular pages seem to work, but the app router is in a buggy/bad state: e.g. things like backward navigation don't work properly (the address bar updates but the UI doesn't).

Additional information

No response

Example

No response

[ztanner]

Hey @steve-marmalade ! Thanks for testing out the canaries. Will indeed be a bit tricky to troubleshoot without a reproduction. One thing I'm curious about though: if you swap out calling a server action + revalidate with instead calling router.refresh, is the reproduction the same? Refresh & server action handling trigger different codepaths so might be helpful to narrow that part down.

[steve-marmalade]

@ztanner , thanks for the quick response!

Yes, the reproduction is the same for router.refresh. I guess that's a win for consistency if nothing else :) I'll keep working at the reproduction, and please don't hesitate to throw out any other things to try.

Quick clarification on router.refresh vs revalidateTag if you have sec. My previous understanding of the benefits of revalidateTag was that:

1. There's only a single server round trip (the refreshed data comes back to the client as part of the mutation)
2. It enables more fine-grained cache updates (since it only needs to re-fetch the fetches/unstable_cache functions that have that specific cache tag).

However, based on #63509, am I correct that only the first one is actually a current benefit? I.e. any revalidateTag will trigger a refetch for all fetch requests on the page, and so we'd need to use a traditional client state management library like useSWR if we want to do more fine-grained revalidations?

[steve-marmalade]

BTW - now that I have public repro, is it helpful for your tracking if I create a Github Issue? And does this one seem trickier to fix than the dynamic params issue / do you advise that I start implementing a workaround while you research?

[ztanner]

No worries! It should be resolved by #64086 :)

[steve-marmalade]

Incredible! Will follow along there.

Quick aside: would you say that it's safe to redirect from within a default.tsx if I don't want a parallel route to be navigable by itself? e.g. scrolling from /q/[query] to /q/[query]/2 should be allowed, but navigating directly to /q/[query/2 (e.g. via browser refresh, or clicking a link in slack) should redirect to /q/[query].

My thought is to put the redirect in /q/[query]/default.tsx, which seems to work, although when I add a console.log, I do see that this default.tsx gets rendered sometimes even when non-default content is visible, like when I do back/forward navigation. When this happens, the redirect itself doesn't actually complete and I haven't observed any obvious negative consequences, but figured I'd ask in case you think there are drawbacks / have another suggestion for how to detect which slots have content.

My other idea was to check for next-url header in middleware.ts to detect a "hard navigation" and then redirect if the URL matches a regex for e.g. q/[query]/2, but I've seen elsewhere that applications are discouraged from depending on next-url directly.

[ztanner]

Redirecting in default seems reasonable to me! I'm curious about the console.log thing you're describing but if it's not actually being rendered, then it won't trigger our RedirectBoundary which handles the redirect.

[steve-marmalade]

That's helpful info thanks! Will see if I can whip up a simple repro for the console.log thing.

The new v14.2.0-canary.58 seems to be working well for me so far! Will keep you posted.