mirror of
https://github.com/KohakuBlueleaf/KohakuHub.git
synced 2026-07-16 10:42:49 -05:00
8f9082d7a9
Two issues surfaced during a make reset-and-seed walk-through against an
existing dev checkout:
1) Backend reported configured_enabled=false even with Valkey running.
Root cause: the contributor's pre-existing .env.dev predates the cache
feature and didn't pick up the new KOHAKU_HUB_CACHE_ENABLED line from
.env.dev.example. ``make init-env`` is intentionally a no-op when
.env.dev exists (per AGENTS.md), so env files drift forever.
Fix is two-layered:
- ``scripts/dev/run_backend.sh`` now defaults
KOHAKU_HUB_CACHE_URL=redis://127.0.0.1:26379/0 if not provided. The
up_infra.sh ensure_valkey step always runs Valkey on host port
26379, so this is correct for any standard local-dev setup. Explicit
env / .env.dev values still win.
- ``config.py`` cache loader now treats the presence of CACHE_URL in
env as implicit-enable when CACHE_ENABLED is unset. Explicit
CACHE_ENABLED=false still wins, so the silent-degradation regression
job in CI keeps validating the off path.
With both layers, ``make reset-and-seed && make backend`` from a stale
.env.dev now boots with the cache live and connected — verified
end-to-end against a clean dev valkey (configured_enabled=true,
client_initialized=true, bootstrap flush completing on first connect).
2) Admin /health page didn't include the cache. Operationally important:
when "low cache hit rate" turns out to be "Valkey unreachable", the
admin UI must surface that signal in the same place the rest of the
dependencies live.
``probe_redis`` added to admin/utils/health.py with the same shape as
the existing probes (PING + INFO server, tight timeout, never raises).
It honors the cache.enabled toggle: configured-off shows up as
``disabled`` (consistent with the smtp probe pattern), configured-on
but unreachable shows up as ``down`` with the underlying connect
error in detail, configured-on and reachable shows up as ``ok`` with
the version field disambiguating Valkey from Redis ("Valkey 7.2.4"
vs "Redis 7.4.0"). The admin UI label is "Redis" for everything else
— protocol identity is what matters operationally.
Verified all three states by toggling KOHAKU_HUB_CACHE_ENABLED and
stopping/starting kohakuhub-dev-valkey while polling the endpoint.
Test updates:
- ``test_health_page.test.js`` SAMPLE_PAYLOAD gains a ``redis`` entry
(status=ok, version="Valkey 8.0.1") so the page test exercises the
new label mapping. Existing assertions use SAMPLE_PAYLOAD.dependencies.length
so they stay correct without mechanical updates.
- All existing cache, config, and admin UI tests still pass (37 backend +
47 admin UI).
Refs: #73, #74
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>