发布

  • [OPIK-7322] fix: pick LLM error model by code type to avoid doomed OpenRouter parse (#7457)

    frostbyte_neo 发布于 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 String code
    (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

    下载附件