Closed tombentley closed 3 weeks ago
Hi, yes, absolutely make sense what you saying, this is partially because of historical reasons, will document better the withKubernetesClient
.
You can change the behavior using .withCloseClientOnStop(false)
.
You can change the behavior using .withCloseClientOnStop(false)
Ah, thanks I didn't manage to spot that!
Bug Report
What did you do?
I wrote a test class with 2
@Test
methods using aLocallyRunOperatorExtension
with an externally-given kubernetes client:What did you expect to see?
Both test methods to be executed
What did you see instead? Under which circumstances?
The first-executed
@Test
method worked fine, but the second failed inAbstractOperatorExtension.beforeEach()
because the previously-executedafterEach
closed the kubernetes client given to the extension viaOperator.stop
.Here's the stack where the client gets closed:
This is surprising to me because my default assumption (when passing a client instance which I've instantiated to some API) is that I remain responsible for closing that client. There is no javadoc to say exactly what the contract of the
withKubernetesClient(client)
method actually is.Environment
N/A
Possible Solution
Either:
withKubernetesClient
, and document the expectation that it's the callers job to close it.withKubernetesClient
is called.Additional context