Studio: drop the on-disk freshness cache after a llama.cpp update - #6234
Conversation
The post-install path cleared only the in-memory freshness caches and then re-primed the 24h disk cache with a forced GitHub refresh. When that refresh cannot reach GitHub, latest_published_release falls back to the last-good disk value, so a still-fresh same-base mix tag cached before the swap (b9596-mix-aaa vs the just-installed b9596-mix-bbb) is replayed and the prebuilt reads as behind, surfacing a false update banner that points back at the build that was just replaced. Give reset_caches a drop_disk option and use it on the update path: with the disk cache gone, an offline post-install refresh leaves latest as None and the banner fails open (off) instead of lingering on the stale same-base value. The no-arg form stays in-memory only. Adds regression coverage for the drop, the default no-op, and the fail-open vs stale-replay contrast.
![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 updates the reset_caches function in llama_cpp_freshness.py to support an optional drop_disk parameter, which deletes the on-disk release cache when set to True. This parameter is utilized during the update process in llama_cpp_update.py to prevent stale cached values from being replayed if a subsequent network refresh fails, allowing the banner to fail open. Comprehensive unit tests have been added to verify these behaviors. There are no review comments, and I have no additional feedback to provide.
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.
1 participant
Summary
Follow-up to the mix-tag freshness work (#6219). The post-install/update path cleared only the in-memory freshness caches, then re-primed the 24h on-disk cache with a forced GitHub refresh. When that refresh cannot reach GitHub (offline, rate-limited),
latest_published_releasefalls back to its last-good disk value. So a still-fresh same-base mix tag cached just before the swap (e.g.b9596-mix-aaawhile the install just moved tob9596-mix-bbb) gets replayed,is_behindreads the prebuilt as behind, and a false update banner points back at the build that was just replaced.Same-base mix-vs-mix tags have no defined ordering between their shas, so the freshness logic cannot disambiguate a stale cached "other" mix from a genuinely newer one. The right fix is to not compare a just-applied install against a value cached before it.
Change
reset_cachesgains a keyword-onlydrop_disk = False. Withdrop_disk = Trueit also deletes the on-disk 24h release cache (a dedicated freshness-only subdir, re-created on the next write). The no-arg form stays in-memory only (its existing test-only contract).reset_caches(drop_disk = True). With the disk cache gone, an offline post-install refresh leaveslatestasNone, socheck_prebuilt_freshnessfails open (banner off) instead of lingering on the stale same-base value. When the refresh does reach GitHub, the disk cache is re-primed with the true newest exactly as before.Test plan
studio/backend/tests/test_llama_cpp_freshness.py, all green (42 freshness + 38 update = 80):drop_disk = Trueremoves the on-disk cache; the no-arg form keeps it;drop_disk = Trueon a missing dir is a quiet no-op.reset_caches(drop_disk = True), yieldslatest_tag = Noneandbehind/stale = False(fails open).behind/stale = True, pinning the exact failure modedrop_diskremoves.