-
After the addition of stale-answer-client-timeout a test was broken due to the following behavior expected by the test. 1. Prime cache data.example txt. 2. Disable authoritative server. 3. Send a query for data.example txt. 4. Recursive server will timeout and answer from cache with stale RRset. 5. Recursive server will activate stale-refresh-time due to the previous failure in attempting to refresh the RRset. 6. Send a query for data.example txt. 7. Expect stale answer from cache due to stale-refresh-time window being active, even if authoritative server is up. Problem is that in step 4, due to the new option stale-answer-client-timeout, recursive server will answer with stale data before the actual fetch completes. Since the original fetch is still running in background, if we re-enable the authoritative server during that time, the RRset will actually be successfully refreshed, and stale-refresh-window will not be activated. The next queries will fail because they expect the TTL of the RRset to match the one in the stale cache, not the one just refreshed. To solve this, we explicitly disable stale-answer-client-timeout for this test, as it's not the feature we are interested in testing here anyways. (cherry picked from commit a12bf4b6)
93ca9686