[hbrundage]

Core dev on IdentityCache here. Excellent point, and truth be told we hadn't considered setting an explicit expiry to let those unavoidable problems fix themselves. We do have a finite amount of space in memcached so the LRU there accomplishes something similar but gaining complete control over the expiry duration does make sense for the reasons you listed. Truth be told however I think I value the flip side of explicit expiry more: we can use any corrupt/un-updated information for debugging which we have done and found really useful in the past. We're also in a way forced to deal with anything which might interrupt our after_commit hooks instead of letting the problem just go away in a day. Hooks firing is also critical for other services we have (like elastic search) that rely on them, and for which I'd rather not create other auto-healers for.

Thanks for the intelligent suggestion!

[elbee]

In some systems the problem is that you can never be guaranteed that the after_commit hook will always run. This is especially true in multi-server systems where the cache, database and front-end servers are separated. The front-end server can update the database and then completely die (power outage, networking, reboot) before talking to the cache.

On the other hand I can see how you would want to drive out bugs instead of just sweeping them under the carpet with auto-healing...

[hbrundage]

Indeed: it will never be 100%, so perhaps a very, very long TTL on the keys would be wise. We do end up flushing the cache incrementally if we ever ship a bug by accident or notice there is more in the cached blob than we want which I think accomplishes the same thing.