Add RestClient timeout support via spring-ai-autoconfigure-http-client module

[drow724]

Hi team,

This PR adds support for configuring RestClient timeouts via the new spring.ai.http.client.connection-timeout and spring.ai.http.client.read-timeout properties.

I understand that some of the previous timeout-related contributions were declined with the reasoning that RestClientCustomizer is the recommended way to control low-level HTTP behavior. However, I’d like to offer a slightly different perspective based on real-world usage and Spring Boot developer experience.

Spring AI clients such as OpenAiChatModel internally construct RestClient using RestClient.builder(), which makes it difficult for users to apply timeout settings without defining custom beans. For many users who just want to quickly call ChatGPT or OpenAI endpoints, defining a RestClientCustomizer bean solely to apply timeout settings is unexpected ceremony.

This PR follows the Spring Boot philosophy of externalized configuration with reasonable defaults, enabling users to declare timeout values in application.yml without writing additional Java code.

A new auto-configuration module (spring-ai-autoconfigure-http-client) is introduced to configure RestClientBuilder via RestClientCustomizer. The customizer is registered only if no other RestClientCustomizer is defined, using @ConditionalOnMissingBean, so it’s fully overridable. The timeout values are backed by a simple @ConfigurationProperties class (SpringAiHttpClientProperties) to keep things clean and idiomatic.

While WebClient timeout support would be useful as well, we chose not to include it yet because the most elegant and standardized way to configure timeouts (via ClientHttpConnectorSettings) is only available in Spring Boot 3.5+. Once Spring AI upgrades its baseline, we plan to extend this same configuration model to support WebClient as well.

This PR is designed to:

• Keep configuration consistent with Spring Boot patterns
• Reduce friction for users who use RestClient implicitly via Spring AI models
• Respect existing extension points (RestClientCustomizer) without overriding user-defined beans

Looking forward to your feedback.

[markpollack]

Super thanks. I've been prototyping some things in this direction. Will take a closer look.

[drow724]

@markpollack Thanks for the feedback!

I’ve added the new spring-ai-autoconfigure-http-client module to the relevant starter pom.xml files where RestClient.Builder is actually used. This ensures that the timeout auto-configuration is available only where it's needed.

Please take a look when you have a moment

[markpollack]

Thanks, trying to continue prototyping, you work is super useful, will get back to you asap.

[markpollack]

We are going to be circling back to this now that GA is over! plesae be patient.

[RyanHowell30]

Hey @markpollack @drow724 .

Would this PR solve connection timeout issues?

Currently using GRPC as the transport. I have a chat client which kicks off, based on the output of this response, I send this to another chat client.

Chat client 1 uses Gemini 2.0 flash. This executes well.

Chat client 2 uses Gemini 2.5 pro. Once I enter this chat client, I get a io.netty.handler.timeout.ReadTimeoutException

If there is a workaround for this, please let me know. The quality in responses when using Gemini 2.5 pro for my agent is night and day compared to both chat clients using 2.0 flash.

[drow724]

Hey @markpollack @drow724 .

Would this PR solve connection timeout issues?

Currently using GRPC as the transport. I have a chat client which kicks off, based on the output of this response, I send this to another chat client.

Chat client 1 uses Gemini 2.0 flash. This executes well.

Chat client 2 uses Gemini 2.5 pro. Once I enter this chat client, I get a io.netty.handler.timeout.ReadTimeoutException

If there is a workaround for this, please let me know. The quality in responses when using Gemini 2.5 pro for my agent is night and day compared to both chat clients using 2.0 flash.

Hey @RyanHowell30

This PR addresses connection timeout configuration only for HTTP clients that use Spring's RestClient (e.g., OpenAI, Mistral, Ollama, etc.).

Since Vertex AI uses gRPC-based transport under the hood via PredictionServiceClient (which in turn uses Netty), the timeout issue you're experiencing (io.netty.handler.timeout.ReadTimeoutException) would need to be addressed through gRPC channel settings, not through this PR.

Hope this helps clarify!