-
Notifications
You must be signed in to change notification settings - Fork 468
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
[conformance] Properly handle lifecycle of an externally passed gRPC client #3156
Comments
Makes sense to me - would this change just be moving the Is there a parallel concern for the HTTP helper too? I'd expect these should have consistent behavior. /assign |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
`MakeRequestAndExpectEventuallyConsistentResponse` no longer calls `Close` on a client that is passed in.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
What would you like to be added:
This issue is for tracking the changes discussed in #3130 (comment)... tl;dr being that
MakeRequestAndExpectEventuallyConsistentResponse()
should not close an externally passed gRPC client.Why this is needed:
The same client could be getting used across multiple tests in parallel. Closing the client should be the responsibility of the place where it was created (and not necessarily within the place where the client gets used)
/cc @snehachhabria
The text was updated successfully, but these errors were encountered: