I'm not sure what's going on here, but it's been causing me a massive amount of pain the past couple of days. Wondering if someone at Vercel could help... Basically I have Sanity hooked into a Next.js 13.5 app using ISR for updating documents when they change in Sanity. Each Sanity request is tagged, e.g. page:/about, and I invalidate those tags using revalidateTag when the corresponding document changes. That all works great once I've deployed the app. However, every time I update the code and push the changes, the site's data regresses. It goes super far back, and always to the same place. I did some experimentation and realized that the point at which the site regresses to is always that of the time of the last build cache. If I redeploy without using the existing build cache, everything shows up up-to-date, and that serves as the new "reset" point for following deploys.

My question is this—does On-demand Revalidation propagate its changes to the fetch-cache subdirectory in the Build Cache? Because if not, my suspicion is that redeploys using the existing build cache are being effectively "reset" back to the time that the build cache was created. It means that every time I push updates to the code, I either have to (a) build without the build cache or (b) manually revalidate all tags across the site. Which are both, obviously, not fun options.