mirror of
https://github.com/KohakuBlueleaf/KohakuHub.git
synced 2026-07-16 10:42:49 -05:00
Brings the L2 cache fully into the operational UI surface and tightens the
local-reset semantics around the cache.
Admin UI surface:
- New Cache page at /cache, modeled on the existing Health page: shows
configured/initialized state, namespace, Valkey memory + maxmemory_policy
+ eviction counter, the bootstrap-flush metadata (last seen run_id,
timestamp, keys flushed), and per-namespace hit/miss/error/set/invalidate
counters with computed hit rate. Auto-refresh selector with 0/5s/15s/60s
options. "Reset counters" button is gated to the operational state and
disabled when the cache is configured-off.
- Three operational states surfaced as a single tag:
* enabled — configured on AND client initialized
* degraded — configured on but client not initialized (silent
fallback to source — operationally important to
surface; without this, "low hit rate" looks like a
miss-heavy workload when actually Valkey is unreachable)
* disabled — configured off
- New AdminLayout nav entry pointing at /cache.
- New API client wrappers getCacheStats / resetCacheMetrics in
src/kohaku-hub-admin/src/utils/api.js, mirroring the read/probe split
used elsewhere.
Tests (test/kohaku-hub-admin/pages/test_cache_page.test.js, 11 cases):
mount + render assertions for each operational state; refresh button
re-fetches; reset confirm dialog flow (both confirmed and cancelled
paths) verified through ElMessageBox.confirm spying; 401/403 force
re-login; missing token redirects to /login; auto-refresh interval
toggles + unmount cleanup. ElMessageBox.confirm is hijacked via
``vi.spyOn`` against the live Element Plus module rather than
``vi.mock("element-plus", ...)``: Element Plus's resolved module identity
inside Vite differs from a test-file ``vi.mock`` interceptor, so spying
on the actual module is the only path that lets the SFC's
``await ElMessageBox.confirm(...)`` land in our test-controllable spy.
Reset semantics:
- ``scripts/dev/reset_local_data.sh`` now follows FLUSHALL with an
explicit synchronous SAVE on the dev Valkey container. Without this
the on-disk RDB still holds entries from before the reset; a Valkey
crash before the next BGSAVE would resurrect cache entries pointing
at repos / commits that no longer exist — observable as ghost cache
hits after ``make reset`` "succeeded".
Refs: #73, #74
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>