@kevin,
Is this something youâre able to reliably reproduce? Weâve only received a couple reports of this over the last few months, and nothing that we could consistently replicate 
That makes troubleshooting really difficult, unfortunatelyâŚ
Either most people arenât having issues (or not noticing them?) or we donât have enough people using cache tags yet⌠hard to say But until we can find some replicable edge case where this keeps happening, itâs really hard to track down and fix. In every test weâve run internally, our systems seem to be behaving appropriately.
UNOFFICIALLY: Iâve been exploring whether we can use other datastores for the cache tag index storage, just for comparison. Officially, we donât have the resources to write and support a bunch of different adapters to various KV/DB services, but unofficially, the process should be straightforward enough that hopefully any dev can make their own adapter for their favorite service, according to their needs.
Our official example uses Turso because it has high free limits and is easy to set up. But itâs not something we can fully control (itâs not in-house and we donât have a formal partnership with them yet). In theory it should be possible to drop in any KV store or DB and test reliability & performance on them.
That said⌠here is an unofficial, unsupported, early pre-alpha, possibly buggy fork of our example that uses Vercel KV instead of Turso. Please note that this is an example only (made for internal testing & debugging), and not something we intend to fully develop & release.
WARNING: Unofficial, unsupported testing branch! Use at your own risk! Click to open...
https://github.com/datocms/nextjs-with-cache-tags-starter/compare/main..arcataroger:nextjs-with-cache-tags-starter:vercel-kv
In my very limited and unscientific personal testing (only a couple hours and a few rebuilds before I ran out of credits on the free Vercel plan), this seemed to be a little more reliable⌠by that, I mean it successfully revalidated every single time.
Of course, our Turso implementation is supposed to work every time, too. I tried very hard to replicate a failed invalidation on our default Turso example, but after many hours of testing, I only made it happen one time (i.e. an invalidation failed one time, as far as I could tell), but I could not find the root cause and could not replicate it again, and Iâm not sure what I did that made it fail =/ I donât have enough evidence to say whether thereâs an edge case issue with their service, a bug in our implementation, some network error, or something else entirely⌠itâs frustrating, I know.
But in my limited tests with the Vercel fork, it seemed to work without issue. Beware that itâs more expensive than Turso (Vercel KV pricing vs Turso pricing), so depending on your budget/billing plan with Vercel, it may or may not be a realistic option. You can also use another KV/DB of your choice, (Netlify Blobs, Cloudflare Workers KV, Redis on GCP/Azure/AWS, your own Redis/Valkey/Memcached/Postgres, etc.) just to see if it makes any difference at all in reliability.
Itâs not something we can officially support, but the underlying mechanisms are not very complex. Most of the underlying datastore provider logic is in just one file: database.ts, that you should be able to modify and hook up to any datastore.
In fact, Vercel KV is basically just a hosted Redis (whitelabeled Upstash), so the commands in my fork should mostly work with any Redis/Valkey-compatible service.
I donât know if this will help, but providing it just in case any of you want to do some testing of your ownâŚ
Sorry, wish I had a better answer here. If anyone does manage to come up with a reproducible example, we will for sure investigate it more!
I wonder if it might be some sort of roles/permissions/API key type thing, where their Dato user isnât triggering the same invalidation workflow as your user wouldâŚ?
