Cache key missing a dimension

What it looks like

• A key built from some but not all of the inputs that change the result.
• A separator removed from a composed key, so different parts can produce the same string.
• A per-user result cached under a key that does not mention the user.

Why it survives review

Every key is well-formed and every lookup succeeds. The cache works — it is just occasionally serving one request's answer to a different request. With one user in a test, or one locale, or one tenant, the missing dimension never varies, so the collision never happens.

How to see it

1. List every input the cached value depends on, then check each one appears in the key. Locale, tenant, permissions and feature flags are the ones that get forgotten.
2. For a composed key, ask whether two different part lists can produce the same string. A separator that can also appear inside a part is not a separator.
3. The worst version of this is a per-user value cached globally. Look for it specifically.

A minimal pair

['ab','c','d'] and ['a','bc','d'] now share a key, and the second lookup gets the first one's value.

Practise it

1 diff in the corpus carry this class. They are not listed, because knowing which diff contains what would make finding it a comprehension question about this page.