tapdb: keep universe root page cache warm across proof inserts#2192
tapdb: keep universe root page cache warm across proof inserts#2192jtobin wants to merge 5 commits into
Conversation
UpsertProofLeaf wiped the leaf keys cache for the same universe ID twice in a row; the two call sites appear to be a merge artifact. Both wipes are per-universe, so the second was pure dead weight.
The rootIndex map was populated in cacheRoots and cleared in wipeCache, but no code path ever read from it. Drop it so the upcoming targeted cache invalidation doesn't need to maintain a structure with no consumers.
Return a universeRootStatus from universeUpsertProofLeaf that indicates whether the upsert created the universe tree or updated an existing one. Creation is detected by reading the tree root before the insert: an empty root is equivalent to the tree being absent, since deleting the last leaf of a universe removes the whole tree. The extra root read is a single point query inside a transaction that already fully decodes the raw proof, so the added cost is negligible. All callers ignore the new value for now; a follow-up uses it to scope root node cache invalidation on the multiverse ingest path.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request optimizes the performance of the universe root node page cache by moving from a global cache invalidation strategy to a targeted one. By distinguishing between universe creation and simple leaf updates, the system can now maintain a warm cache for existing universes during proof ingestion, significantly reducing database load for paginated queries. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request optimizes the universe root node page cache by implementing targeted invalidation instead of wiping the entire cache on every proof leaf insertion. Now, when a proof leaf is inserted, the system checks if a new universe was created or an existing one was updated. If a new universe is created, the cache is wiped; if an existing universe is updated, the cache is patched in place. The feedback suggests optimizing the batch upsert by caching the check for whether the cache was wiped, thereby avoiding redundant patchRoot calls and mutex acquisitions.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Every proof leaf insert used to wipe the entire root node page cache across all universes, keeping AssetRoots pagination permanently cold on a busy server. But the page cache is keyed by pagination parameters only, and the backing UniverseRoots query orders by the stable universe_roots.id column, so inserting a leaf into an existing universe never changes which page its root appears on: the cached copies of that root can be patched in place, the same way the adjacent syncer cache is already updated via addOrReplace. Only two events actually change page composition and still wipe the page cache: creating a new universe (first leaf) and deleting one. Pages fetched with grouped asset amounts can't be patched without a database query, so an update evicts exactly those pages that contain the changed root. The batch insert path applies the same logic: one wipe if any item created a universe, otherwise an in-place patch per updated root. A model-based rapid property test asserts the central invariant: the cache may miss at any time, but a page it serves must always equal a fresh database read, and handed-out pages are never mutated. A deterministic test covers cache warmness across single and batch inserts, creation wipes, and amounts-page eviction.
|
@jtobin, remember to re-request review from reviewers when ready |
2 participants
Previously, every proof leaf insert wiped the root node page cache across all universes, so any server ingesting proofs at a steady rate served AssetRoots pagination permanently cold; every page request fell through to the database.
The fix is targeted invalidation: inserting into an existing universe can't change which page its root appears on, so the insert now patches the cached root in place, and only universe creation and deletion still wipe the cache. A property test pins the invariant that the cache may miss, but never serves a page that differs from a fresh database read.