Spring-Boot-Version: 3.3.3

In my Spring-Boot-Integration-Test i use the WebClient in an Service. I dont use any mocks in this Test-Class.

When i look into ClientRequest ( what is called as Part of initRequestBuilder()) it looks like this:

    static Builder create(HttpMethod method, URI url) {
        return new DefaultClientRequestBuilder(method, url);
    }

Only a DefaultClientRequestBuilder is created that looks like this:

    public DefaultClientRequestBuilder(HttpMethod method, URI url) {
        Assert.notNull(method, "HttpMethod must not be null");
        Assert.notNull(url, "URI must not be null");
        this.method = method;
        this.url = url;
    }

So there should be no way that the ClientRequest is null.

But somehow i get this Error:

java.lang.NullPointerException: Cannot invoke "org.springframework.web.reactive.function.client.ClientRequest$Builder.headers(java.util.function.Consumer)" because the return value of "org.springframework.web.reactive.function.client.ClientRequest.create(org.springframework.http.HttpMethod, java.net.URI)" is null

What is special about my test: - I use MockMvc to do an initial request to the application - I use @DynamicPropertySource - I use MockWebServer

What is special about this error: - It only fails on Jenkins

Because i am not able to debug while running in Jenkins i tried debugging it locally to see whats going on.

Locally it sets the Url and the Method and it works as expected so i dont see an issue here.

Do you have an explanation for this different behaviour regarding the WebClient and especially the ClientRequest class?

I would provide you a minimal example but i dont know how to reproduce the issue.

Comment From: bclozel

There's nothing much we can do I'm afraid if we can't reproduce the problem. The fact that you're mixing both a live server (MockWebServer) and MockMvc in the same test is already really concerning in my opinion. Unless the client is used by the controller directly?

Given your description, this doesn't ring any bell nor point to a particular problem in our codebase.

Anyway, I'll close this issue for now but we can reopen it as soon as you can provide a minimal sample that reproduces the problem.

Comment From: NicoStrecker

There's nothing much we can do I'm afraid if we can't reproduce the problem. The fact that you're mixing both a live server (MockWebServer) and MockMvc in the same test is already really concerning in my opinion. Unless the client is used by the controller directly?

Given your description, this doesn't ring any bell nor point to a particular problem in our codebase.

Anyway, I'll close this issue for now but we can reopen it as soon as you can provide a minimal sample that reproduces the problem.

Why is it problematic to do a integration test with mockmvc (to call the endpoint) and mockwebserver (to fake responses from other services) and yeah sure i investigate further

Comment From: bclozel

Why is it problematic to do a integration test with mockmvc (to call the endpoint) and mockwebserver (to fake responses from other services) and yeah sure i investigate further

It's not. I probably misunderstood the setup. It's hard to infer a complex setup like this without anything concrete. Yes please, let us know if you manage to reproduce locally.

Comment From: NicoStrecker

I was able to reproduce it by running it multiple times over and over somehow isMockedStatic is called even if i have no mockito setup in this test case i investigate further if i find out why this is the case

Comment From: NicoStrecker

The ClientRequest is Mocked in another TestClass with mockStatic(ClientRequest.class); but in my understanding this should not affect other tests i even tried @DirtiesContext but that didnt help either

Comment From: NicoStrecker

Seems like someone forgot to close the mock what is mentioned in the Documentation

The returned object's ScopedMock. close() method must be called upon completing the test or the mock will remain active on the current thread.

Thank you a lot and sorry that i had a non related issue @bclozel