Skip to content
  • Diego Fronza's avatar
    Adjusted serve-stale test · 93ca9686
    Diego Fronza authored and Matthijs Mekking's avatar Matthijs Mekking committed
    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