Hello, I'd like to check on the topic of revalidation.

I was trying to use revalidatePath just to delete the cache based on a request via Sanity webhook. In page router it worked "quite ok" via res.revalidate(route) but it did not work well for many routes. One important aspect... the next page visit provided an updated version.

Based on docs in the app router, revalidatePath should be perfect compared to the old res.revalidate.

I dug into next.js code as the behavior does not reflect docs (or maybe I'm not reading it right).

- revalidatePath('/[slug]', 'page') - works
- revalidatePath('/some-name', 'page') - does not work
- revalidateTag('unique-tag') - works
- revalidateTag('shared-tag') - works

I can see that everything is channeled through revalidateTag with a constructed implicit tag in patch-fetch.ts#L103.

However, all revalidation seems to work in a way that the page needs to be visited to kick off a new render, while the server returns the cached version, and then on the subsequent visit, it returns the latest cached version. This was the problem with revalidate: 0 and it was solved with explicit res.revalidate().

Could anyone shed some light on this?
1. Why url pathname does not work?
2. Is fetch further configurable to get updated content at the next page visit and not the second visit? (I don't want to opt-out from the cache, just get updated content at once)

Minimalistic example with some info in README here: https://github.com/quirm/revalidate-test