Backport of Fix panicky xDS test flakes into release/1.15.x #16310
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.
Backport
This PR is auto-generated from #16305 to be assessed for backporting due to the inclusion of the label backport/1.15.
The below text is copied from the body of the original PR.
Description
I'm seeing a bunch of panics in some flaky testing code in our xDS package. The relevant stack traces that come up time and again seem to mostly be on ARM (I'm assuming that this is due to some sort of slowness in the test runs that are accentuating race conditions due to additional qemu translation? 🤷):
Notice the
DeltaAggregatedResources(0x4001581620, {0x2998370, 0x0})
-- the first argument should be the pointer address to the xds server itself, the second is the first argument of theDeltaAggregatedResources
function (stream ADSDeltaStream
), which, since it's an interface is a tuple of the type information and then the actual pointer to the underlying type, which isnil
.We seem to be
nil
ing the argument that gets passed there in our test helpers while cleaning up after a test run, which, if any requests are in flight will pretty much cause any of our handler code to panic and the tests to abort (hence the ridiculous amount of flake).Really we should probably fix the testing code so it doesn'tnil
something that's often unconditionally dereferenced and also potentially used in a multithreaded context (I wouldn't be surprised if there were still panics due to only nil checking once and using it later in the function), but this is a simple attempt to at least make the tests fail less often, and I'd prefer this for now than to potentially heavily refactor the testing code (I'm also not sure what tests rely on thenil
behavior of the stream).Edit: Introduced a boolean guard in the test code itself that should hopefully fix the panics since we were still hitting them due to this being multithreaded. Doesn't appear like anything relies on the
nil
, so hopefully that should be fine.PR Checklist
Overview of commits