Module redis 

Redis-backed L1 hot cache StorageBackend.

This is the sub-millisecond top tier of the tiered super-cache resolver (Redis L1 → Postgres L2 → object L3). It maps a content-addressed key (the 32-char store-path hash for narinfo, or the relative NAR URL — which is itself content-derived; when the daemon addresses graph blobs the key is GraphHash::display_short()) to its stored value.

It is a cache, not a source of truth

A key may vanish under Redis maxmemory LRU eviction at any moment, and RedisBackend::list_narinfos therefore returns only the currently-resident hot subset — never an authoritative listing. Durability/correctness comes from the durable tiers below it in a TieredBackend; a hot-only write that a pod roll loses must always be re-derivable from L2/L3. Because the key is content-derived, an L1 miss satisfied by a lower tier returns the same bytes for the same key — read-through transparency.

TTL / eviction awareness

Writes are optionally stamped with a per-write TTL (RedisBackend::with_ttl); with no TTL, entries rely on the Redis maxmemory band’s LRU policy (the super-cache controller derives redis.maxmemory_mib from the memory band). Either way the backend treats a missing key as a plain cache miss (Ok(None)).

The client seam (Environment / testability contract)

RedisBackend is generic over RedisConn — the minimal async redis verb surface it needs. Unit tests inject an in-memory mock; production injects [RedisConnectionManager] (a multiplexed, auto-reconnecting redis::aio::ConnectionManager, behind the redis-client feature). The pure L1 semantics are proven against the mock with no live Redis required.

Structs

RedisBackend

L1 hot cache: content-addressed key → value, sub-ms hits, TTL/eviction-aware.

Traits

RedisConn

The minimal async redis verb surface RedisBackend depends on.