Newly added areas not listed right away

[vnugent]

Steps to Reproduce

1. Add a new a area. Example (Parent -> New area)
2. Visit the parent area. The newly added area isn't listed

I believe 2 changes contribute to the caching issue:
a. we recently made an adjustment to Cloudflare cache (turn on Proxy for openbeta.io)
b. longer area page cache https://github.com/OpenBeta/open-tacos/pull/1234/files#diff-95ae8c28eafa1b51054aba9cd1574da984871e3fb0c47e615a4ea5da78231e35

[enapupe]

I think it's option b, I've checked headers and

cf-cache-status: DYNAMIC
x-vercel-cache: HIT

perhaps there should be some cache invalidation logic when publishing a new area?
I believe this is the relevant docs https://nextjs.org/docs/app/api-reference/functions/revalidatePath

[vnugent]

I think it's option b, I've checked headers and

cf-cache-status: DYNAMIC
x-vercel-cache: HIT

perhaps there should be some cache invalidation logic when publishing a new area? I believe this is the relevant docs https://nextjs.org/docs/app/api-reference/functions/revalidatePath

We're calling a custom function to revalidatePath after every update. Maybe it doesn't get called in this case?

[enapupe]

The docs for revalidatePath says:

revalidatePath(path: string, type?: 'page' | 'layout'): void;
path: Either a string representing the filesystem path associated with the data you want to revalidate (for example, /product/[slug]/page), or the literal route segment (for example, /product/123). Must be less than 1024 characters. This value is case-sensitive.
type: (optional) 'page' or 'layout' string to change the type of path to revalidate. If path contains a dynamic segment (for example, /product/[slug]/page), this parameter is required. If path refers to the literal route segment, e.g., /product/1 for a dynamic page (e.g., /product/[slug]/page), you should not provide type.```

we are calling it like:

 revalidatePath(`/area/${uuid}`, 'page')

So I suppose we should not specify page since we are invalidating literal routes.

[vnugent]

I believe the GraphQL queries are also cached because Next replaces the underlying fetch() used by Apollo client. In summary, we want the page to be cached, not hitting the API on each request, but after an edit, we invalidate both the page and GQL queries.

https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamic

[mikeschen]

Closing. This bug seems to be fixed.