test: fix flaky xds_failover StartupPrimaryNotResponding for GoogleGrpc TRANSIENT_FAILURE#46006
Draft
yanavlasov with Copilot wants to merge 3 commits into
Draft
test: fix flaky xds_failover StartupPrimaryNotResponding for GoogleGrpc TRANSIENT_FAILURE#46006yanavlasov with Copilot wants to merge 3 commits into
yanavlasov with Copilot wants to merge 3 commits into
Conversation
…pc TRANSIENT_FAILURE When the primary XDS server closes a TCP connection, the gRPC channel can enter TRANSIENT_FAILURE state. If Envoy's simulated-time retry timer fires before the gRPC channel's real-time backoff expires, the new stream attempt is rejected immediately by the gRPC library (without a TCP connection being established). This counts as a 2nd consecutive failure and triggers failover - without any new TCP connection arriving at the fake upstream. The test's second primaryConnectionFailure() then waits 30s (ASAN) for a TCP connection that never comes because Envoy has already switched to failover. This manifests as the "Please don't waitForHttpConnection with a 5s timeout if failure is expected" assertion, aborting the test. Fix: before calling primaryConnectionFailure() the second time, poll (without advancing simulated time) for the cds.update_failure counter to reach 2. If it reaches 2 within 200*TIMEOUT_FACTOR ms, it means the 2nd failure happened via TRANSIENT_FAILURE and we skip the explicit connection close step. Signed-off-by: Copilot <copilot@github.com> Co-authored-by: yanavlasov <6360027+yanavlasov@users.noreply.github.com>
…values Co-authored-by: yanavlasov <6360027+yanavlasov@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Fix failing GitHub Actions job for ASan
test: fix flaky xds_failover StartupPrimaryNotResponding for GoogleGrpc TRANSIENT_FAILURE
Jul 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
XdsFailoverAdsIntegrationTest.StartupPrimaryNotResponding/15(IPv6, GoogleGrpc, UnifiedDelta) fails intermittently under ASAN due to a race between gRPC's real-time channel backoff and Envoy's simulated-time retry timer.Root cause
After the first
primaryConnectionFailure()closes the TCP connection, the gRPC channel entersTRANSIENT_FAILUREwith a ~1s real-time backoff.waitForPrimaryXdsRetryTimer()advances simulated time, firing Envoy's retry timer before that real-time backoff expires. The gRPC library immediately rejects theestablishNewStream()attempt (no TCP connection made), which counts as the 2nd consecutive failure and triggers failover. The test's secondprimaryConnectionFailure()then waits 30s (ASANDefaultTimeout) for a primary TCP connection that never arrives — Envoy has already switched to failover — hitting theRELEASE_ASSERT.This race is timing-sensitive: for IPv4 the gRPC library fast-retries before
onEstablishmentFailurefires (channel stays inCONNECTING), so the race doesn't manifest there.Fix
In
StartupPrimaryNotResponding, before the secondprimaryConnectionFailure()call, poll (real-time only, no simulated clock advancement) forcds.update_failure ≥ 2within200×TIMEOUT_FACTORms. If the counter reaches 2, the 2nd failure already occurred viaTRANSIENT_FAILUREand the explicit TCP-close step is skipped:Polling uses real time (not
advanceTimeWait) to avoid firing additional simulated timers that could interfere with test state. The200×TIMEOUT_FACTORwindow is well above the typical <60ms propagation latency for the gRPC completion queue → Envoy main thread path.Files changed
test/extensions/config_subscription/grpc/xds_failover_integration_test.cc— TRANSIENT_FAILURE detection +absl/timeincludestest/extensions/config_subscription/grpc/BUILD— added@abseil-cpp//absl/timedep