HTTP interface client should not set a default blockingTimeout value and instead let the underlying HTTP client determine the behavior

[pmverma]

Affects: Spring Boot 3.0.5 / Spring Framework 6.0.7

---

As mentioned in the title, it seems the webclient timeout value does not work when using the HTTP interface.
But the same timeout value works when using the webclient directly as below.

    @EventListener
    public void onStartup(ApplicationStartedEvent event) {
        // Non-blocking, working fine
        event.getApplicationContext().getBean(WebClient.class)
                .get()
                .uri("http://localhost:8080/test")
                .retrieve().bodyToMono(String.class)
                .subscribe(System.out::println);

        // Blocking, working fine
        String result = event.getApplicationContext().getBean(WebClient.class)
                .get()
                .uri("http://localhost:8080/test")
                .retrieve().bodyToMono(String.class)
                .block();
        System.out.println(result);

        // Blocking but with HttpInterface, is failing
        SampleApi sampleApi = event.getApplicationContext().getBean(SampleApi.class);
        System.out.println(sampleApi.get().getStatusCode());
    }

I have added a minimal sample application that demonstrates the above issue.
https://github.com/pmverma/demo-http-interface-webclient-timeout

All codes are in a single file DemoHttpInterfaceWebclientTimeoutApplication.java

Regards,
Mohan

[pmverma]

I found that it is not related to WebClient, but HttpServiceProxyFactory itself where you can need set the .blockTimeout.

        HttpServiceProxyFactory factory = HttpServiceProxyFactory.builder(WebClientAdapter.forClient(webClient))
                .blockTimeout(Duration.ofSeconds(30))
                .build();

This should be mentioned in the documentation as this is a bit tricky.
It says the Http interface uses WebClient, but the timeout configuration for blocking calls has nothing to do with it.

[OlgaMaciaszek]

Hello, @pmverma, thanks for reporting this. Although the blocking timeout settings were set there on purpose, we realise it might be more useful and intuitive to have any timeouts being governed by the underlying HTTP clients' settings. We are going to modify it so that the blockingTimeout is null by default and only there to be set explicitly by the developers for their convenience.

[rstoyanchev]

Closing as superseded by #30403.