internal/dns: update TestDNSResolver_ExponentialBackoff to not return error before last resolution attempt #8061
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #7760
The
TestDNSResolver_ExponentialBackoff
test verifies that the DNS resolver correctly implements exponential backoff when encountering errors. It simulates a failing resolver and forces it to retry 10 times. The test overrides the standardtime.After
function, used for backoff delays, with a custom implementationoverrideTimeAfterFuncWithChannel
which uses two channels:durChan
to receive the intended backoff duration from the resolver, andtimeChan
to signal the resolver that the waiting period is over. In each iteration of the test loop (representing a retry attempt), the test first reads fromdurChan
to verify if the back off happened. Because of the test setup, this read usually gets the backoff duration from the previous resolution attempt (including the first attempt from resolver build). The test then immediately unblocks the resolver by sending a signal totimeChan
.The problem arose in the last iteration. The loop would exit without reading the last backoff duration from
durChan
, and right after, the test would set an atomic bool flagreturnNilErr
to true to make the resolver's update function succeed. However, a race condition existed: if the resolver happened to start its 10th and final resolution attempt before this flag was set to true, that attempt would fail, trigger a backoff and consequently put a value intodurChan
. The test expected this final attempt to always succeed because of the flag being set right after exiting the loop. The test then checked ifdurChan
was empty, and if it wasn't (meaning an unexpected backoff occurred), the test would flake. The fix resolves this by ensuring that the flag to force a successful update is set before the last resolution attempt begins. This guarantees that the last attempt will always succeed, eliminating the possibility of an unwanted backoff and ensuring thatdurChan
remains empty, thus preventing the test from flaking.Forge run without fix: https://fusion2.corp.google.com/invocations/4f183c2c-f5cf-4fee-a18d-d5c4da2479bc/targets/%2F%2Fthird_party%2Fgolang%2Fgrpc%2Finternal%2Fresolver%2Fdns:dns_test/tests
Forge run with fix: https://fusion2.corp.google.com/invocations/3bab8892-5a85-4758-bc3f-8437191bffbe/targets/%2F%2Fthird_party%2Fgolang%2Fgrpc%2Finternal%2Fresolver%2Fdns:dns_test/log
RELEASE NOTES: None