Cached items get removed when upstream fetch is unsuccessful

[agneevX]

Prerequisites

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Issue Details

• Version of AdGuard Home server:
  • 0.107.3
• How did you install AdGuard Home:
  • Docker
• How did you setup DNS configuration:
• If it's a router or IoT, please write device model:
• CPU architecture:
  • arm64
• Operating system and version:
  • Ubuntu 20.04.3

Issue Details

It seems that cached records get deleted when an upstream query is unsuccessful, after the cached query is served.

I lost at internet at 5:16:29 PM, so when the query was made one second later, a cached query was served.
At 5:36:31, when the internet was back up already, the query was fetched from upstreams, instead of from the cache.

However I'd say this requires some more testing.

Additional Information

I remember v0.107.0 serving cached records for an infinite amount of time when upstreams were unreachable. This is why actually the network was functional even though I had misconfigured upstreams, funny story!

[EugeneOne1]

@agneevX, hello. The responses are cached for a TTL value they had so that the upstream server won't be queried until the response expires. If you have the "Optimistic caching" enabled, the last response should only be returned one more time. In any case the expired cache items are removed if those couldn't be resolved again so I would say this is the intended behavior. Did my answer clarified the logic?

[agneevX]

If you have the "Optimistic caching" enabled, the last response should only be returned one more time. In any case the expired cache items are removed if those couldn't be resolved

I do have Optimistic Caching enabled. I don't think this behavior is right, it should still serve expired queries rather than deleting items it could not get a reply to.

Has this behavior changed recently? While I'm using DNS-over-HTTPS resolvers now, this was not the case before.

[EugeneOne1]

@agneevX, well, you're right. This is a bug, we'll fix it soon.

[agneevX]

Thanks @EugeneOne1 as always 👍