I'm not sure if I've found a defect or not, but here goes.

I'm calling a url in which the resulting Cache Entry ttl and softttl are the same (i.e. the response can be/is cached, but there is no soft caching enabled). But, in certain edge cases, if another request for the same url is sent right before (like a few milliseconds) the cache ttl value, it will still perform the soft caching behavior resulting in 2 responses getting delivered (one from the cache, and then a fresh response from the network moments later).

I believe the issue is in the CacheDispatcher.processRequest() method. In that method, it first checks for a completely expired cache item (line 142 ... if (entry.isExpired())). At this point, the entry is NOT expired, so this block is (correctly) skipped. Several lines later, it checks for a soft expiration (line 167 ... if (!entry.refreshNeeded())), and if there is a soft expire, then it'll deliver the cached response, and make a fresh network call and then delivery that response. As I mentioned, in my case there is no soft caching enabled in the response headers. The ttl and softttl on the cache entry get the same value. To me, that should mean it's impossible to generate a soft expiration. But what happens is that line 142 is executed a millisecond or 2 before the expiration (so it's not expired), and then by the time it gets to line 167, a few milliseconds have gone by and it checks for a soft expiration and now the time has passed the expiration and it determines that it has indeed hit the soft expiration.

It seems like the check for entry.isExpired() and entry.refreshNeeded() should happen at the exact same moment (same millisecond) so that the CacheDispatcher can properly handle an edge case where it's process an entry as the cache time is expiring.