matslina
commented
4 months ago I believe the main motivation for including TTL in cache key was to protect against apps accidentally using a giant TTL, which would then leave the developer unable to have a fix (with lower TTL) take effect until the (giant) TTL has expired. With TTL in cache key, changing the TTL is equivalent to evicting the old record, from the app's perspective.
But I think we can do this. I don't recall ever seeing anyone accidentally using too large a TTL, but plenty of people have wanted to dynamically change TTL without read-through.
dinosaursrarr
See discussion on Discord. Multiple times, app developers have wanted to cache a piece of content until a particular time, rather than for a particular period. That requires setting ttl_seconds to a variable amount, calculated as the time remaining.
Currently, the cache client won't support that. It generates the cache key from the entire request, which includes the TTL seconds in a header. This change removes that header before generating the key. That seems sensible because the key should be about the content and how it would be fetched, but the TTL is about what to do with the response.
As a transitionary step, this writes to new TTL-less keys, but continues to look up keys with TTLs. Once all the old cache entries have expired, then we can stop looking up the old keys.