stale-derived-state

The stale cache or derived state that never invalidates

Something is written. Something else is derived from it and was computed earlier. The write path never tells the derived thing to recompute, so the screen, the session config, the lookup table or the client store keeps serving the value it already had. A reload rebuilds everything from source and the problem disappears, which is exactly why it gets reported as intermittent when it is not.

The diagnostic move is to prove the write landed and the read did not reflect it. Crumbtrail is good at the first half and only partly good at the second.

Symptom

A user changes a setting, renames something, toggles a permission or saves a record. The interface accepts it. The new value does not appear. Reloading the page, logging out and back in, or navigating away and returning makes it appear.

A second phrasing is the opposite direction: a value that should have been cleared keeps coming back, or a list that should now be empty keeps rendering its previous contents.

What Crumbtrail can see

The honest limitation first, because it decides how you spend the next few turns. The cache that failed to invalidate is usually an in memory object: a client store, a module scoped map, a memoized selector, a server side lookup table. None of that is recorded. Crumbtrail instruments the boundaries a value crosses, not the heap it sits in. If the value never crossed a boundary, the recording cannot show it to you.

What the recording does carry, all of which are boundaries a stale value tends to cross:

• Storage writes with the storage type, the operation, the key, and the old and new values. Keys and values that look sensitive come back replaced with a redaction marker, so you may see that a key changed without seeing what it changed to.
• Cookie changes.
• Every request and response, so the write and the later read are both present with their bodies. This is the strongest available proxy: a read issued after the write that returns the old value proves the staleness is on the server or in a shared cache rather than in the browser, and a read that never happens at all proves the opposite.
• Navigation events, which matter because this archetype is defined by what a reload fixes.
• Database row changes with before and after column values, but only where the database adapter is installed. This is what turns "the write probably landed" into a fact.