Cache performs two gets on misses

[akursar]

We observe two cache.get() calls whenever we miss. The first attempt is made in CacheController.cached_request(). We see the "No cache entry available" in logs. However, we immediately see another cache.get() call after this. This seems to be because CacheController.conditional_headers() makes another call to self.cache.get(). This doesn't appear to be ideal, but I'm not sure what change to propose. I see some other usage of self.cache.get in the Controller as well. Since we don't rely on etag/last-modified headers, we may just use a custom Controller that has a condition_headers that simply returns {}, but raising here to see if there's any shared appreciation for trying to limit the number of get calls to make to the cache, or ideas for how otherwise to improve that.

[MANAS225]

This is a great observation, thanks for raising it.

I agree that on a cache miss we currently end up calling cache.get() twice — once in cached_request() and again in conditional_headers(). On a miss, the second lookup can’t add any information, and for non-in-memory backends (Redis, disk, etc.) it’s potentially an unnecessary cost.

At the same time, I can see why the logic ended up this way, since conditional_headers() needs access to the cached response for ETag / Last-Modified handling, and keeping the methods independent avoids tighter coupling.

A couple of possible directions that came to mind (without strongly advocating any particular one yet):

• Pass the cached response (or an explicit “miss” sentinel) from cached_request() into conditional_headers() so we don’t re-query the cache on a known miss.
• Cache the result of the initial get() call on the controller instance for the duration of the request.
• Make the conditional header behavior configurable, so users who don’t rely on ETag / Last-Modified can opt out cleanly without subclassing.

That said, I agree this touches core behavior and probably needs consensus before proposing a concrete change. Curious to hear if others have run into similar concerns, or if maintainers have thoughts on whether reducing duplicate cache lookups is something worth pursuing.