core.cache TTL cache expiration visibility between lookup and has?

Answer

For a TTL cache created with ttl-cache-factory (the default lazy implementation), lookup (get) returns nil for an expired entry, while the presence check (has? or contains?) still reports the key as present. Consequently, a read‑through helper that first checks has? and then calls get will treat an expired entry as a hit and may return a stale nil value instead of recomputing.

Confirmed facts

• Lookup applies the TTL filter: it compares the stored expiration timestamp with the current time and returns nil when the entry has expired.
• Presence checks only test for the key’s existence in the underlying map; they do not consult the expiration timestamp.
• The read‑through pattern "if (has? cache k) then (get cache k) else …" therefore sees an expired key as a hit and does not trigger a recompute unless the helper also treats a nil result from get as a miss.
• The authoritative freshness check is the lookup operation itself (get), because it is the only API that enforces the TTL condition.

Steps to verify the behavior

1. Create a TTL cache with a short TTL, e.g. (def c (ttl/ttl-cache-factory :ttl 100)) (100 ms).
2. Insert a value: (def c2 (assoc c :k "value")).
3. Wait longer than the TTL (e.g. (Thread/sleep 200)).
4. Check lookup: (get c2 :k) → should be nil.
5. Check presence: (has? c2 :k) (or (contains? c2 :k)) → should be true.
6. Optional: implement a simple read‑through helper and observe whether it recomputes after the wait.

When the recommendation might change

If you have enabled a background reaper (e.g. via a custom cache factory that performs eager eviction), the key may be removed from the map after expiration, causing both get and has? to report a miss. In that case the read‑through helper would behave correctly without modification. Please confirm whether your cache uses a reaper thread before adjusting the helper.