Complexity rank: 7 of 15
Priority: High
Selection criteria satisfied: 3 (advertised capability is a stub) · 2 (multi-instance cache divergence)
Scope tier: Standard
Description:
api-server/src/cache.rs:1-4 and :22 document "Redis-based caching layer... falling back gracefully... when Redis is unavailable." There is no Redis client anywhere in the file: static STORE: Lazy<DashMap<String, Entry>> = Lazy::new(DashMap::new); is the sole backing store, unconditionally, for every code path. Behind a load balancer with two or more api-server instances, each holds independent cache state — a write invalidation processed by invalidate_on_contract_event (cache.rs:204-261) only clears the calling instance's local entries, so a client whose read lands on a different instance can observe stale data indefinitely after a contract event that should have invalidated it.
Tasks:
- Implement a real Redis-backed store behind the existing
cache.rs API surface, with the documented graceful fallback to in-process memory only when Redis is genuinely unreachable (with a logged/metriced degraded-mode signal, not a silent permanent fallback).
- Ensure
invalidate_on_contract_event invalidates the shared Redis-backed entry so all instances observe the invalidation, not just the instance that received the triggering event.
- Add a connection-health check that flips the fallback flag and recovers automatically once Redis becomes reachable again.
- Add a test proving a value cached via one simulated instance and invalidated via another is no longer served stale by the first (using two
Cache handles pointed at the same Redis instance in a test).
- Add a test proving the documented fallback path (Redis unreachable) still serves correct, if not shared, cached data rather than erroring.
- Preserve the existing public
cache.rs function signatures so call sites elsewhere in the crate don't need to change.
- Confirm
docs/api-reference.md/module doc comments describe the fallback behavior as it now actually works, including the degraded-mode signal.
Complexity rank: 7 of 15
Priority: High
Selection criteria satisfied: 3 (advertised capability is a stub) · 2 (multi-instance cache divergence)
Scope tier: Standard
Description:
api-server/src/cache.rs:1-4and:22document "Redis-based caching layer... falling back gracefully... when Redis is unavailable." There is no Redis client anywhere in the file:static STORE: Lazy<DashMap<String, Entry>> = Lazy::new(DashMap::new);is the sole backing store, unconditionally, for every code path. Behind a load balancer with two or moreapi-serverinstances, each holds independent cache state — a write invalidation processed byinvalidate_on_contract_event(cache.rs:204-261) only clears the calling instance's local entries, so a client whose read lands on a different instance can observe stale data indefinitely after a contract event that should have invalidated it.Tasks:
cache.rsAPI surface, with the documented graceful fallback to in-process memory only when Redis is genuinely unreachable (with a logged/metriced degraded-mode signal, not a silent permanent fallback).invalidate_on_contract_eventinvalidates the shared Redis-backed entry so all instances observe the invalidation, not just the instance that received the triggering event.Cachehandles pointed at the same Redis instance in a test).cache.rsfunction signatures so call sites elsewhere in the crate don't need to change.docs/api-reference.md/module doc comments describe the fallback behavior as it now actually works, including the degraded-mode signal.