Claus Ibsen created CAMEL-24552:
-----------------------------------
Summary: 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
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)
