k-krawczyk opened a new pull request, #25887: URL: https://github.com/apache/camel/pull/25887
Fixes [CAMEL-24552](https://issues.apache.org/jira/browse/CAMEL-24552). `OpenAIEndpoint.configureHttpClient()` wired a single duration into the SDK builder via `builder.timeout(Duration)`. That call is exactly `Timeout.builder().request(d).build()`, so it set the request phase only and left the connect phase on the SDK default of one minute. The richer `com.openai.core.Timeout` was never used. ### Change Three additive `@UriParam` options on `OpenAIConfiguration`, all in milliseconds, all defaulting to `0` meaning "leave the SDK default alone": | Option | SDK default | Bounds | | --- | --- | --- | | `connectTimeout` | 1 minute | Establishing the TCP connection | | `readTimeout` | falls back to `requestTimeout` | Reading the response | | `writeTimeout` | falls back to `requestTimeout` | Writing the request body | `configureHttpClient()` now builds a `Timeout` from whichever phases are set, and skips the call entirely when none are. The motivation is the one in the issue: a connect-phase timeout means the request never reached the model and is safe to retry, while a read-phase timeout means the model may have processed it already, so a blind retry can duplicate work and cost. ### Backwards compatibility Setting only `requestTimeout` produces the same `Timeout` instance the previous single-duration call produced, so no existing route changes behaviour. The only other change to existing state is the `requestTimeout` javadoc, which now says it acts as the fallback for the read and write phases. The large diff in `openai.json` is the generator renumbering `index` after three options were inserted in alphabetical order. ### Verification `OpenAIClientConfigurationTest` grows four cases asserting the resulting `ClientOptions.timeout()`: all four phases set at once, `connectTimeout` alone with the other phases left on SDK defaults, read and write falling back to `requestTimeout`, and URI parsing. Those cover configuration, not behaviour, so `OpenAIReadTimeoutTest` closes the loop end to end: the mock accepts the connection and then stalls for 20s, and with `readTimeout=500` the exchange fails in about half a second with a `SocketTimeoutException` in the cause chain. Removing the `readTimeout` parameter from that route makes the same test run the full 20s and fail, so it is not passing for an unrelated reason. Ran the test eight times consecutively after fixing one flake: OkHttp does not always place `SocketTimeoutException` at the root of the cause chain, so the assertion searches the chain via `Exchange.getException(Class)` instead of asserting on the root. `-Psourcecheck` passes. _Reported by Claude Code on behalf of Karol Krawczyk_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
