Repository navigation
Commit 47f960a
committed
xds: Fix intermittent failure in RingHashLoadBalancerTest.allSubchannelsInTransientFailure
Deliver TRANSIENT_FAILURE in deterministic server order using subchannelList
instead of iterating over subchannels.values() (HashMap), and expect 2
connections.
Why this became flaky with the new PickFirst LB:
Old PickFirst unconditionally invoked subchannel.requestConnection() on each
call without checking connection state, so triggering proactive connections
twice always produced 2 connection requests regardless of iteration order
(either [A, B] or [A, A]).
New PickFirst deduplicates connection requests if a subchannel is already in
CONNECTING state. When iterating over a HashMap, if the same subchannel was
triggered twice, New PickFirst deduplicated it to 1 connection, leading to the
assumption in grpc#13094 that New PickFirst would always yield 1 connection.
However, if two distinct subchannels were triggered (e.g. server1 then server2),
New PickFirst does not deduplicate and yields 2 connections, causing
verifyConnection(1) to fail intermittently.
Fix this by iterating deterministically in server order, which reliably triggers
two distinct subchannels (server1 and server2) in both old and new PickFirst.
TAG=agy
CONV=d59ec8a0-3bb7-41f8-bb11-76e843a2dada1 parent 2c9b067 commit 47f960a
1 file changed
Lines changed: 3 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
719 | 719 | | |
720 | 720 | | |
721 | 721 | | |
722 | | - | |
| 722 | + | |
723 | 723 | | |
724 | 724 | | |
725 | | - | |
| 725 | + | |
726 | 726 | | |
727 | 727 | | |
728 | 728 | | |
729 | 729 | | |
730 | 730 | | |
731 | 731 | | |
732 | | - | |
| 732 | + | |
733 | 733 | | |
734 | 734 | | |
735 | 735 | | |
| |||
0 commit comments