k-krawczyk opened a new pull request, #25886: URL: https://github.com/apache/camel/pull/25886
Fixes [CAMEL-24550](https://issues.apache.org/jira/browse/CAMEL-24550). The AI producers propagate their SDK's typed exceptions unchanged, so route authors can already write targeted error handling today. None of it was documented, so this adds it. ### camel-openai The `Error Handling` section grows three subsections: - **Targeting SDK exceptions with onException** - table of the eight `OpenAIServiceException` subclasses with their status codes and whether a retry makes sense, plus the three status-less types (`OpenAIIoException`, `OpenAIRetryableException`, `OpenAIInvalidDataException`). Includes an `onException` example separating retryable from terminal, and one reading `statusCode()` / `code()` / `type()` off the exception. - **SDK retry vs Camel redelivery** - the SDK retries internally before Camel sees anything. At the default `maxRetries=2` one exchange already issues three HTTP requests, and `maximumRedeliveries(3)` on top of that multiplies to twelve against an endpoint that is already rate limiting you. Documents both ways to pick a single layer. - **Errors in streaming mode** - with `streaming=true` the producer hands back an `Iterator`, so a failure after the first chunk surfaces at the consuming step (usually Split), not at the `to("openai:...")` step. ### camel-langchain4j-chat New `Error Handling` section. LangChain4j's hierarchy already encodes the retry decision through `RetriableException` and `NonRetriableException`, so most routes need only those two. Notes that the mapping is done by the model implementation rather than by Camel, and covers model-level `maxRetries` multiplying with Camel redelivery the same way. ### LLM Integration Guide Cross-component section comparing what each component throws, so readers can find the right types without opening three pages. ### Note on Spring AI The issue suggests documenting Spring AI alongside the others. In Spring AI 2.0.0 `spring-ai-openai` is built on `openai-java` and contains no reference to `org/springframework/ai/retry`; no module in the 2.0.0 set uses `RetryUtils`, and `camel-spring-ai-chat` does not depend on `spring-ai-retry`. So `TransientAiException` / `NonTransientAiException` is not what a user would catch. The guide states that the types depend on the `ChatModel` bean and that an OpenAI-backed one throws `com.openai.errors.*`, rather than documenting a pattern that would not fire. ### Verification Status codes and retry behaviour in the tables were read from the shipped artifacts rather than from memory: the eight status codes from `openai-java-core-4.49.0`, the retry policy (408, 409, 429, 5xx, `IOException`, honouring `Retry-After`) from `RetryingHttpClient`, and the attempt arithmetic from the retry loops in both SDKs. Documentation only, no code changes. _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]
