-
[OPIK-7322] fix: pick LLM error model by code type to avoid doomed OpenRouter parse (#7457)
发布于
2026-07-14 08:39:20 +00:00 - [OPIK-7322] fix: pick LLM error model by code type to avoid doomed OpenRouter parse
getErrorObject attempted the OpenRouter error model (Integer
code) first
for every provider error. OpenAI-compatible providers (which back every
caller, including OpenRouter via LlmProviderOpenAi) return a Stringcode
(e.g. "rate_limit_exceeded"), so the OpenRouter attempt threw
InvalidFormatException - caught and logged as a WARN stack - on every such
error. Attempt the OpenRouter model only when error.code is numeric;
otherwise use the OpenAI model directly. This removes the doomed parse and
its WARN stack while keeping OpenRouter's numeric-code mapping intact:
reordering unconditionally would coerce OpenRouter's Integer code into
OpenAI's String field and degrade 429 to 500.Adds a mapper test covering both code shapes and asserting no parse-failure
WARN is logged for the string-code path.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7322] test: assert on ErrorMessage payload, drop log assertions
Addresses PR review: don't test log output (volatile, non-critical, 3rd-party
inner detail). Removed the logback ListAppender / WARN-emptiness assertions and
kept the behavioral coverage on the resolved ErrorMessage status code. The
OpenRouter numeric-429 case still guards the reorder regression (numeric code
must resolve to 429, not be coerced to a 500).Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件