Skip to content
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

Surprising closing of caller-supplied clients #2562

Closed
tombentley opened this issue Oct 27, 2024 · 2 comments · Fixed by #2564
Closed

Surprising closing of caller-supplied clients #2562

tombentley opened this issue Oct 27, 2024 · 2 comments · Fixed by #2564
Assignees

Comments

@tombentley
Copy link

Bug Report

What did you do?

I wrote a test class with 2 @Test methods using a LocallyRunOperatorExtension with an externally-given kubernetes client:

    @RegisterExtension
    LocallyRunOperatorExtension extension = LocallyRunOperatorExtension.builder()
            .withKubernetesClient(client)
            .withReconciler(ProxyReconciler.class)
            .build();

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 in AbstractOperatorExtension.beforeEach() because the previously-executed afterEach closed the kubernetes client given to the extension via Operator.stop.

Here's the stack where the client gets closed:

doClose:254, OkHttpClientImpl (io.fabric8.kubernetes.client.okhttp)
close:300, StandardHttpClient (io.fabric8.kubernetes.client.http)
close:160, BaseClient (io.fabric8.kubernetes.client.impl)
stop:181, Operator (io.javaoperatorsdk.operator)
stop:189, Operator (io.javaoperatorsdk.operator)
after:201, LocallyRunOperatorExtension (io.javaoperatorsdk.operator.junit)
afterEachImpl:178, AbstractOperatorExtension (io.javaoperatorsdk.operator.junit)
afterEach:89, AbstractOperatorExtension (io.javaoperatorsdk.operator.junit)

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:

  • Don't close the client passed via withKubernetesClient, and document the expectation that it's the callers job to close it.
  • Or document that responsibility for closing the client passes to the extension when withKubernetesClient is called.

Additional context

@csviri
Copy link
Collaborator

csviri commented Oct 28, 2024

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).

@tombentley
Copy link
Author

You can change the behavior using .withCloseClientOnStop(false)

Ah, thanks I didn't manage to spot that!

@csviri csviri linked a pull request Oct 28, 2024 that will close this issue
@csviri csviri self-assigned this Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants