Expand description
Mode 2 response cache — in-memory LRU keyed by the 7-input SHA-256
composition from .yah/docs/architecture/mesofact.md §“Cache-key
composition”, with the fresh / stale (SWR) / expired state machine from
§“Mode 2 caching beyond TTL”.
Invalidation is generation-driven, not purge-driven: each source’s current generation token (sqlite file mtime, r2 Last-Modified, …) is folded into the key (input 6), so a backend bump yields a different key and an automatic miss on the next request — no reverse tag index needed in the hot path.
Structs§
- Cache
Entry - A cached render result plus the TTL/SWR window it was stored under.
- KeyInputs
- The ordered inputs to the cache key. Maps are
BTreeMapso iteration is already sorted — input 3 (params), 4 (query), 5 (vary), and 6 (source generations) all require deterministic key order. - Response
Cache - Thread-safe LRU response cache.
get/inserttake&self; theMutexguards theLruCache(whosegetneeds&mutto bump recency).
Enums§
- Cache
State - Freshness verdict for a stored entry at a given instant.
Constants§
- DEFAULT_
CAPACITY - Default LRU capacity (entries). Tunable via
ResponseCache::with_capacity.
Functions§
- cache_
window - Caching policy by status class (§“Mode 2 caching beyond TTL”):
2xx/3xx cache under
ttl+swr; non-2xx (4xx) cache undernegative_ttlwith no SWR window; 5xx is never cached. Returns(ttl, swr)to store under, orNoneto skip caching. - compose_
key - Compose the SHA-256 cache key as a lowercase hex string. Each field is fed with a label and a record separator so component boundaries can’t collide (e.g. a param value can’t impersonate a query key).