[jira] [Work started] (CAMEL-24552) Expose phase-specific timeouts (connect/read/write/request) on camel-openai instead of a single overall timeout

["Karol Krawczyk (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-24552 started by Karol Krawczyk.
----------------------------------------------
> Expose phase-specific timeouts (connect/read/write/request) on camel-openai instead of a single overall timeout
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24552
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24552
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-openai
>            Reporter: Claus Ibsen
>            Assignee: Karol Krawczyk
>            Priority: Minor
>
> OpenAIEndpoint.configureHttpClient() currently wires only a single overall duration into the SDK builder via builder.timeout(Duration.ofMillis(...)), driven by the existing requestTimeout URI option.
> However, the underlying openai-java SDK's com.openai.core.ClientOptions.Builder / OpenAIOkHttpClient.Builder accepts a richer com.openai.core.Timeout object with independently configurable phases:
> - connect(Duration)
> - read(Duration)
> - write(Duration)
> - request(Duration)
> Camel ignores this richer builder entirely and only ever sets the single overall request timeout.
> Proposed fix: add new @UriParam options on OpenAIConfiguration (e.g. connectTimeout, readTimeout, writeTimeout) that, when set, build a com.openai.core.Timeout via its Builder and pass it to configureHttpClient() instead of (or in addition to) the existing single requestTimeout. Keep requestTimeout as the overall/backwards-compatible default when the new options are not set.
> Motivation: distinguishing a connect-phase timeout (the API was unreachable) from a read-phase timeout (the model was slow mid-generation) matters for deciding what's safely retryable versus not — see CAMEL-24550 (documenting targeted onException/retry handling) and CAMEL-24551 (structured AI error metadata), which this complements.
> This is additive/backwards compatible — no existing behavior changes unless the new options are explicitly set.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)