mirror of
https://github.com/jcreek/CosmicClash.git
synced 2026-09-10 16:04:04 +00:00
79ab0d1404
Closes part of the 'live Redis failover' gap in §8.46, found by reproducing a genuine Redis outage (not just an empty/partial cache) against CandidateProjection.Snapshot with a killed miniredis instance. CandidateProjection.Snapshot funnelled two different situations into the same code path: the index erroring outright (Redis unreachable) and the index coming back empty (ambiguous — a genuinely empty queue, or a lost keyspace). Both went through Repair, which itself calls Index.Rebuild — a second Redis round-trip that fails for exactly the same reason the first one did. The result: a real Redis outage, or the window during a failover, made Snapshot fail outright even though PostgreSQL — the documented authoritative source everywhere (RedisCandidateIndex's own comment, cmd/matcher, cmd/control-plane's --redis-addr help text all call it a rebuildable/optional acceleration layer) — was completely healthy. Matchmaking would stop entirely on a Redis outage despite the architecture explicitly not requiring that. Snapshot now falls back to serving Source (PostgreSQL) directly whenever the index errors OR comes back empty, and only best-effort attempts to repopulate Redis afterward — that attempt's outcome is deliberately ignored, since a caller must never be denied service just because the opportunistic rebuild also hit the same down Redis. Snapshot still fails when Source itself is unavailable; the fallback is not unconditional. Verified: reproduced the bug first (killed-miniredis Snapshot call failed even though Source was healthy), then fixed it. go build/vet clean; all pre-existing store-package tests pass unmodified, including the two live-redis:7-alpine-container tests (TestRealRedisCandidateIndexUpsertSnapshotRemove, TestRealRedisCandidateProjectionRepairsAfterFlush, run against a real container and torn down after). Two new tests cover the fallback directly (killed miniredis, Source still served, exactly one Source call) and that the fallback is not unconditional (both Redis and Source down still fails). Full go test ./... -race clean across every server package. Remaining: live matcher-worker-under-load-during-failover integration, i.e. running the actual matcher process against a real Redis that goes down mid-run under concurrent load, not just this unit-level reproduction.