Skip to content

Error-class-bound fallthrough for OpenRouter models[] fallback#334

Merged
jpr5 merged 1 commit into
mainfrom
feat/openrouter-error-class-fallthrough
Jul 23, 2026
Merged

Error-class-bound fallthrough for OpenRouter models[] fallback#334
jpr5 merged 1 commit into
mainfrom
feat/openrouter-error-class-fallthrough

Conversation

@jpr5

@jpr5 jpr5 commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Error-class-bound fallthrough for the OpenRouter models[] fallback engine

Follow-up to #328. That PR shipped models[] failover (an error-fixture candidate falls through to the next model, unless provider.allow_fallbacks:false). But real OpenRouter fails over inconsistently by error class — the loudest authentic user complaint (openclaw#60191, #45834, #19249): a 403 budget-exceeded or generic "provider error" does not advance to the next model (it retries the same primary), while 429/503 do. Users can't rehearse that.

What this adds

An optional fallthrough?: boolean on the error fixture response:

  • absent (default) → current behavior: the error candidate falls through to the next models[] candidate (fully backward-compatible).
  • fallthrough: false → the error is terminal: the loop stops and serves that error, no failover — reproducing "this error class doesn't fail over."

It composes with the request-level provider.allow_fallbacks:false (either signal makes an error terminal). A dev models an error class by setting fallthrough:false on that class's fixture (e.g. the 403) and leaving 429/503 fixtures to default — so they can reproduce the exact failure that burned them and assert their handling, and the positive "fallback saved me" path.

Correctness

  • Load-time validation: validateFixtures rejects a non-boolean fallthrough ("false", 0, null) — without this, a JSON author's "false" string would silently invert TERMINAL→fall-through (fail-closed quietly failing open).
  • A winning non-error slug is echoed as response.model; a terminal error is served as the OpenRouter error envelope ({error:{code,message,metadata?}}, no model field).
  • Default path is byte-identical to OpenRouter chat/LLM router simulation #328's fall-through.

Testing / review

  • Red→green against the real HTTP surface; new tests for fallthrough:false terminal, default fall-through, composition, and the non-boolean load-time rejection.
  • Full suite green (pnpm test); tsc/lint/build/exports clean. No version bump (release is separate).
  • Reviewed via a multi-round CR (converged; silent-failure clean, gate/threading/validation confirmed correct).

🤖 Generated with Claude Code

https://claude.ai/code/session_018yy1y2Cwc31DaB4UNqvT8K

Add an optional `fallthrough?: boolean` to the ErrorResponse fixture type.
In the OpenRouter models[] fallback loop, when a matched error response sets
`fallthrough: false`, treat it as terminal (stop the loop, serve that error,
no failover) instead of falling through to the next candidate. Absent/`true`
keeps the current backward-compatible fall-through.

This reproduces OpenRouter's inconsistent-by-error-class failover: a 403
budget-exceeded / generic provider error is served as terminal, while 429/503
fail over. The per-fixture gate composes with the request-level
`provider.allow_fallbacks`: fall-through happens only when BOTH allow it.

Threads the field through types.ts (ErrorResponse) and the fixture-loader
(response-level, carried by the existing normalizeResponse shallow clone).
validateFixtures rejects a non-boolean `fallthrough` at load, so the
fail-closed half cannot silently fail open on a "false"/0/null author typo.
Documents it in the OpenRouter docs fallback section and write-fixtures skill.
@pkg-pr-new

pkg-pr-new Bot commented Jul 23, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@copilotkit/aimock@334

commit: a93f8fc

@jpr5
jpr5 marked this pull request as ready for review July 23, 2026 01:54
@jpr5
jpr5 merged commit 94de974 into main Jul 23, 2026
24 checks passed
@jpr5
jpr5 deleted the feat/openrouter-error-class-fallthrough branch July 23, 2026 01:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant