[herjarsa]

Problem

When a combo has multiple models from the same provider and one returns a connection-level error (408/500/502/503/504/524), the combo engine continues trying every remaining target from the same provider one-by-one, each wasting time before eventually failing.

Solution

Add a per-request exhaustedConnections Set (keyed by provider:connectionId) that marks a provider connection as exhausted when a target fails with a connection-level error. Subsequent targets with the same provider:connectionId are skipped immediately.

Changes

• Priority path (combo.ts): Add exhaustedConnections skip check before existing exhaustedProviders check; mark connection on 408/500/502/503/504/524
• Round-robin path (combo.ts): Same pattern
• Network errors (DNS, ECONNREFUSED): Already converted to 502 by handleSingleModelWithTimeout's .catch() — covered automatically
• 429 and 499: Handled separately (transientRateLimitedProviders and immediate combo stop) — not affected

Tests

• Updated 2 circuit-breaker test assertions (now expect 2nd same-provider target to be skipped)
• 75/75 tests passing
• typecheck:core clean

Verification

ℹ tests 75
ℹ pass 75
ℹ fail 0

[gemini-code-assist]

Code Review

This pull request introduces connection-level error tracking to skip remaining targets on a known-bad connection (e.g., 502/503/504 errors) for both standard and round-robin combo routing. However, the accompanying unit tests were updated to assert failure because both test models share the same provider, bypassing the fallback logic. The reviewer suggests updating the second model in these tests to a different provider to properly verify that fallback still occurs for circuit breaker responses.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The test is named "handleComboChat treats provider circuit breaker responses as ordinary target failures". Its purpose is to verify that when a target returns a circuit breaker response (503), the engine treats it as a non-fatal failure and successfully falls back to the next target.\n\nHowever, because both models in the test are on the same provider (openai/model-a and openai/model-b), the new same-provider connection-level error skip logic immediately skips openai/model-b. As a result, the test now asserts result.ok is false and calls is ["openai/model-a"], which means it no longer verifies that fallback actually occurs for circuit breaker responses.\n\nTo preserve the original intent of the test while keeping the new skip logic, please change the second model in the test setup (line 2085) to a different provider (e.g., "anthropic/model-b"), and then assert that result.ok is true and calls contains both models.

[gemini-code-assist]

Similar to the priority strategy test above, this round-robin test is named "handleComboChat round-robin treats provider circuit breaker responses as ordinary target failures". Because both models are on the same provider (openai), the second model is skipped, and the test no longer verifies that round-robin fallback actually succeeds for circuit breaker responses.\n\nPlease change the second model in the test setup (line 2621) to a different provider (e.g., "anthropic/model-b") and update the assertions to expect result.ok to be true and calls to be ["openai/model-a", "anthropic/model-b"].

[diegosouzapw]

Merged into release/v3.8.22 — thanks @herjarsa! 🎉 The per-connection / per-provider skip on connection-level errors (408/500/502/503/504/524) is a solid improvement. During review I added one fix-in-place commit: a circuit-breaker guard. A provider circuit-breaker-open response is a 503 (X-OmniRoute-Provider-Breaker: open / provider_circuit_open), so the new skip logic was catching it and poisoning exhaustedProviders/exhaustedConnections — which would skip remaining same-provider targets while the breaker is open, regressing the invariant that breaker-open is an ordinary target failure. I added isProviderCircuitOpenResult to exclude it from both the priority and round-robin blocks, and reverted the two circuit-breaker tests to use two same-provider (openai) targets again so they prove breaker-open does NOT skip same-provider. Credited you as author + me as co-author. Shipping in the next release.