hi, writing again regarding this issue. i have found out why this leads to cache misses for us. in the absence of a transaction during the current quantization window, new revisions will be computed from pg_current_snapshot. this will normally lead to each node computing the same revision. it does not in our case because our database is on a shared postgres server, so pg_current_snapshot will include transactions from other databases. this is a production issue for us since even if a transaction gets written to the table right after the start of the quantization window, as we issue way more reads than writes, most likely the revisions are already computed at that point, each node having computed a different revision. at least i'll be able to convince the infra team to provision a dedicated db instance for us 🙂

Hey @Omar , thanks for reporting this. This is indeed a problem we did not anticipate and sounds like it would cause caching to thrash completely. I've been exploring some options as part of https://github.com/authzed/spicedb/pull/2247 because with my chances in, SpiceDB itself will start causing the snapshot to move on a regular interval when client uses the Watch API.

Hi, thanks for fixing this. We had also observed large namespace query latencies despite the watchable schema cache being enabled. It sounds like there were some changes regarding this, in the presence of transactions from other applications on the db? Looking forward to trying this out with the next release

I'm going to likely change the flag name, so be aware, working on a follow up PR to have this enabled by default

correct