-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xdsclient: switch xdsclient watch deadlock test to e2e style #5697
Conversation
4656275
to
651dc63
Compare
651dc63
to
654219b
Compare
Ping @dfawley |
internal/testutils/xds/e2e/server.go
Outdated
wait := true | ||
if opts != nil { | ||
wait = !opts.AllowResourceSubset | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait := opts == nil || !opts.AllowResourceSubset
Or can we make this a required parameter (i.e. not a pointer) to simplify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the callsites to StartManagementServer
are happy with the defaults and therefore they dont pass anything to this function. So, making this not a pointer will change most callsites from passing nil
to an empty struct.
I changed it to the single line alternative you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's not used extensively, it might be worth changing before it's used even more often. nil checks can make the code more complicated and there isn't much benefit to passing a pointer instead of a value here.
if rdsCancel2 != nil { | ||
rdsCancel2() | ||
} | ||
if rdsCancel3 != nil { | ||
rdsCancel3() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this not race with the setting of these variables (in the event of an error)? I.e. if you make watch #2 on rdsNameNewStyle
instead (or expect it to match the wrong thing), maybe the race detector will fire because rdsCancel3
could be set while you're running this defer after the Fatal
.
Do we even need this defer? Can we cancel the watch inside the callback instead after doing the Send
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Moved these to use t.Cleanup()
and they look much nicer now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 2 other nil checks in that function already that could also be simplified.
Filed an issue to track this. |
Improve a test which verifies that the xdsclient does not deadlock if a new watch is called inline from a watch callback, by moving to an e2e style test which verifies functionality without relying on any internal state.
This PR is similar to how the LDS watchers test was cleaned up in #5506.
#resource-agnostic-xdsclient-api
RELEASE NOTES: n/a