mirror of
https://github.com/ipnet-mesh/meshcore-hub.git
synced 2026-07-26 19:42:47 +02:00
Louis King
b6740068d3
After PR #311's invalidation wiring and HTTP policy fix, a user reported the routes list still showed stale data for ~30s after a PUT. The HAR they sent actually showed the fix working (x-cache: MISS after PUT, fresh data returned) but had been captured with DevTools' 'Disable cache' enabled — so it didn't represent normal browsing. We had four competing hypotheses and no way to pick between them. Add structured INFO logging at the two points that matter: * meshcore_hub.api.cache_invalidation._drop now emits 'Cache invalidate start: prefix=... backend=...' and 'Cache invalidate ok: prefix=...'. The backend= field distinguishes RedisCacheBackend from NullCache in one glance, catching 'REDIS_ENABLED is actually false' cases. * meshcore_hub.common.redis.RedisCacheBackend.delete now emits 'Redis cache delete: prefix=... full_prefix=... keys_deleted=N scan_iterations=N'. keys_deleted=0 after a mutation that should have invalidated entries is the smoking gun for a cache-key mismatch between the store path (key_builder) and the delete path (prefix glob). * NullCache.delete emits a DEBUG line for the same reason. The error paths are also enriched with full_prefix for greppability. No behavioral changes — invalidation still swallows errors so cache outages never break a write. After deploy, a single route-edit repro will produce log output whose shape (start/ok/warning/missing, keys_deleted count) unambiguously identifies which of the four hypotheses is correct, so we can write a targeted fix instead of guessing.