On refreshing the router, since you found it sometimes works: it clears the client cache and re-fetches the current route from the server. It does nothing to the server-side caches.
So it fixes the case where the server already has fresh data and the browser is showing a stale copy. It cannot help when the server is itself serving cached data, you will re-fetch and receive the same stale value, which is the case where you found it did nothing.
Which gives you the rule for choosing:
- Server invalidation for things that changed on the server. This is nearly always what you want, and it should be in the action.
- A router refresh for the narrower case where the client needs to re-read something the server will now render correctly, a session change after login, for example.
- Both only when you have a specific reason, not by default.
A debugging move that makes this quick: after the action runs, open the network tab and see whether the browser actually asked the server for anything. If there was no request, it is the client cache. If there was a request and the response contained old data, it is a server cache. That single observation tells you which of the two categories you are in, and you stop guessing.
And if you are returning updated data from the action itself, be careful that you are not writing a value into the UI that then disagrees with what the next fetch produces. That combination produces a value that appears correct and then reverts, which is a third symptom people conflate with these two.