Why does a `weakref.WeakValueDictionary` cache of parsed log schemas keep emptying itself?

### What the container actually promises `weakref.WeakValueDictionary` maps ordinary strong keys to **weakly referenced values**. The entry vanishes automatically when its value is garbage collected. The sibling containers behave analogously: `weakref.WeakKeyDictionary` holds keys weakly, and `weakref.WeakSet` holds members weakly. Read that promise carefully and the failure becomes obvious. The mapping never keeps a value alive. It is a way to *find* an object that something else already owns. Used as a memoization cache, where the mapping is meant to be the reason the object still exists, it does nothing at all. ### The failure in practice Picture a log-ingest pipeline that parses one schema object per emitting service across a 17-service dependency graph, and caches them by service name in a `weakref.WeakValueDictionary`. The parse function builds the schema, stores it, returns it. The caller uses it for one batch and drops it. The refcount hits zero, the value is collected, the mapping quietly removes the entry. The next batch parses all 17 schemas again. Nothing raises, no log line appears, `len(cache)` reads zero, and the symptom is a cache that silently truncates itself to empty while CPU sits in the parser. It is a slow, invisible bug precisely because the container is doing exactly what it documents. The reverse mistake produces the opposite symptom. If some long-lived structure -- a registry, a logging handler, a closure captured in a callback -- holds a strong reference to every value, nothing is ever collected and the "weak" cache grows without bound. Weak containers only shrink when the rest of the program lets go, so unbounded growth means you have an ownership problem elsewhere, and `weakref.getweakrefcount` plus a look at what refers to a sample value is where the investigation starts. ### Fixing it The cure is to decide, explicitly, what keeps values alive and for how long. The common pattern is a **strong floor under a weak index**: keep a bounded strong structure -- a fixed-size `collections.deque` of recently used values, or a `functools.lru_cache`-style bounded mapping -- so the last N entries cannot be collected, and let the weak mapping catch everything beyond that which the wider program still happens to hold. That gives a real hit rate for hot keys with a hard memory ceiling, and it makes the retention policy a number you chose rather than an emergent property of unrelated code. If what you actually wanted is a plain bounded cache, use a bounded strong cache and stop there; weakness buys you nothing. The genuine use for weak-valued mappings is **canonicalization**: an interning table or identity map where the requirement is "if this object exists anywhere, everyone must get the same one", and where the table must not be the thing that keeps it alive. There the automatic eviction is the whole point. ### Two further traps **Not every value can be stored.** The value must support weak references, so a `str`, `int`, `tuple`, `list` or `dict` value raises `TypeError: cannot create weak reference to ...` at insertion time, as does an instance of a class whose `__slots__` omits `'__weakref__'`. A cache keyed by service name and holding plain strings simply cannot be built this way. **Size and iteration are advisory.** Because entries disappear whenever the collector runs, `len()` is a snapshot that may be stale by the next line, and a `for` loop over the mapping can see entries removed underneath it. The containers guard against mutation during iteration internally by deferring removals until the iteration finishes, but that also means the mapping can hold entries fractionally longer than you expect while iterating. In a threaded program, the safest habit is to materialize a list of the values you care about -- which incidentally takes strong references and pins them for the duration -- rather than looping over the live mapping and hoping. ### How to talk about this The short diagnosis an interviewer wants: the container holds values weakly, nothing else was holding them, so they were collected immediately and the entries went with them. The senior half of the answer is what you do next -- name the retention policy explicitly, put a bounded strong structure underneath, and reserve weak-valued mappings for identity maps where automatic eviction is the requirement rather than an accident.