[
https://issues.apache.org/jira/browse/CAMEL-24551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109436#comment-18109436
]
Karol Krawczyk commented on CAMEL-24551:
----------------------------------------
I looked at this while working on CAMEL-24550 and hit three things worth
settling before any code goes in.
*1. Setting the properties next to observation.recordError() would make them
conditional on observability being present.*
GenAiObservability.start() returns a NOOP observation when observability is
disabled via properties, or when camel-ai-observability is simply not on the
classpath (see start() and resolveBridge()). Error metadata that a route's
error handler depends on would then silently vanish for anyone not using
tracing. The classification needs to happen in the producer's catch block, or
in a shared helper called from it, rather than through the observation object.
*2. CamelAiRetryAfterMillis can only be populated for OpenAI.*
com.openai.errors.OpenAIServiceException exposes headers(), so Retry-After is
reachable there. dev.langchain4j.exception.RateLimitException carries neither
headers nor a status code; its only constructors take String and Throwable. So
the property would be present for camel-openai and absent for the langchain4j
components. Worth deciding deliberately rather than discovering it later.
CamelAiErrorCategory is achievable everywhere.
*3. camel-ai-observability-api cannot see com.openai.errors at compile time.*
That module depends on camel-support and langchain4j-core only. The langchain4j
hierarchy (RetriableException / NonRetriableException) can be matched directly,
but the OpenAI types would need either class-name matching or a per-component
classifier contributed by the module that has the SDK on its classpath. All
five producer modules already depend on camel-ai-observability-api, so it is
the right home either way.
Happy to implement whichever direction you prefer.
_Reported by Claude Code on behalf of Karol Krawczyk_
> Expose structured error metadata (category, retry-after) as Exchange
> properties when an AI producer call fails
> --------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24551
> URL: https://issues.apache.org/jira/browse/CAMEL-24551
> Project: Camel
> Issue Type: Improvement
> Components: camel-openai
> Reporter: Claus Ibsen
> Priority: Major
>
> When OpenAIProducer (and the equivalent langchain4j/spring-ai producers)
> catch a RuntimeException before rethrowing it for observability (e.g.
> OpenAIProducer.java ~714-738), they currently only call
> observation.recordError(e). Propose also setting a small set of Exchange
> properties derived from the underlying SDK exception, e.g.:
> - CamelAiErrorCategory (e.g. RATE_LIMIT, SERVER_ERROR, VALIDATION, AUTH,
> UNKNOWN) — classified from the SDK's typed exception hierarchy
> (RateLimitException, InternalServerException, UnprocessableEntityException,
> BadRequestException, UnauthorizedException).
> - CamelAiRetryAfterMillis — populated when available (e.g. from a 429's
> Retry-After header), so an onException handler can react without reaching
> into SDK-internal exception fields.
> This should live in the shared camel-ai-observability-api module (or a
> similarly shared camel-ai module) so all four producers (openai,
> langchain4j-chat/agent/embeddings, spring-ai-chat) get it consistently rather
> than duplicating logic. No behavior change to what's thrown — properties are
> additive, set right before the exception propagates.
> Related to CAMEL-24550 (documentation for targeted onException handling),
> which should reference these new properties once available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
