Next.js Discord

Discord Forum

How to force the deletion of a built static page file?

Unanswered
Philippine Crocodile posted this in #help-forum
Open in Discord
Philippine CrocodileOP
My team is using Craft CMS as the backend to our React/Next.js(v14.2.4) web client and are observing odd behavior. When a content creator creates a new page in the CMS a custom Craft plugin makes a request out to the Next.js server /api/revalidate endpoint for the new page. This works out fine when we publish a new page, but when we either disable or delete a page the page data is retained and navigating to the direct URL in the client shows the page data until we do a full client rebuild. The /api/revalidate endpoint is being called when the disable/deletion event occurs, and I was under the impression that this would trigger the Next.js server to query for the newly disabled/deleted page data, get nothing back, and then delete the static built file from the ./.next directory. This is not happening though - is there any way via the Next.js API to force the deletion of a statically built file?

9 Replies

@Philippine Crocodile My team is using Craft CMS as the backend to our React/Next.js(`v14.2.4`) web client and are observing odd behavior. When a content creator creates a new page in the CMS a custom Craft plugin makes a request out to the Next.js server `/api/revalidate` endpoint for the new page. This works out fine when we publish a new page, but when we either disable or delete a page the page data is retained and navigating to the direct URL in the client shows the page data until we do a full client rebuild. The `/api/revalidate` endpoint is being called when the disable/deletion event occurs, and I was under the impression that this would trigger the Next.js server to query for the newly disabled/deleted page data, get nothing back, and then delete the static built file from the `./.next` directory. This is not happening though - is there any way via the Next.js API to force the deletion of a statically built file?
no, nextjs ISR works this way:
* when /api/revalidate is hit, a revalidation happens in the background
* when the revalidation hasn't finished yet, incoming users still see the stale data
* when the revalidation has successfully finished, the new version will be used from there onwards
* but if the revalidation fails, the stale page is still kept and rendered, while nextjs tries to revalidate the page on the subsequent request

so I assume in your case, the revalidation failed, by a throw new Error or something like that. which means nextjs will keep trying in vain to revalidate the page, while users will keep seeing the old page.

you should also gracefully handle the case where the page is deleted/disabled and render something, like "This page is disabled" or "This page is deleted" or notFound() or anything. just ensure the revalidation completes successfully.
Philippine CrocodileOP
The revalidation doesn't fail though, that's the issue
I don't think it deletes built files from the .next directory. you may need to wait some time to revalidation finishes
I think that's acceptabe stale data and if you need your changes reflected instantly you need to consider server side rendering or client side rendering
Philippine CrocodileOP
I don't think it deletes built files from the .next directory. you may need to wait some time to revalidation finishes
We've waited far past the revalidation period, checking back the next day to see it still pulling up the page. How is this not a bug? Seems like at best a terrible feature
I think that's acceptabe stale data and if you need your changes reflected instantly you need to consider server side rendering or client side rendering
We've had our eye on SSR for awhile not, perhaps it's time to finally make the jump
@Philippine Crocodile The revalidation *doesn't* fail though, that's the issue
could you make a reproduction repository here then? because from your description, ISR is simply not working. would be interested in seeing a minimal reproduction.
Philippine CrocodileOP
Okay my peer has found the culprit (https://github.com/vercel/next.js/issues/37945), it appears to be related to our need to set isrMemoryCacheSize to 0 . This is necessary for our setup as we run in a Kubernetes orchestration (https://github.com/vercel/next.js/discussions/38858) where the built files are mounted to the replicated Next.js client pods from a persistent volume. So it seems to be a known bug and the fix is a workaround to explicitly purge the file and return the 404.