test(combo): guard same-provider cascade is handled by connection cooldown (#3200) - #3194
Merged
Merged
Conversation
…tion cooldown (#3200) Regression guard born from the TDD evaluation of PRs #3145/#3169. Proves that when a combo has multiple targets from the same provider and that provider fails (404 or 5xx), the existing connection-cooldown marks the connection unavailable after the FIRST failure, so the remaining same-provider targets are pre-screened out before dispatch — the provider is hit exactly once, then the combo falls back to a different provider. This locks in the current behavior so a future change can't silently regress the cascade guard. No production code changed (test-only).
Contributor
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
This was referenced Jun 5, 2026
HouMinXi
pushed a commit
to HouMinXi/OmniRoute
that referenced
this pull request
Aug 2, 2026
…tion cooldown (diegosouzapw#3200) (diegosouzapw#3194) Integrated into release/v3.8.11
Poid-ZA
pushed a commit
to Poid-ZA/OmniRoute
that referenced
this pull request
Aug 5, 2026
…tion cooldown (diegosouzapw#3200) (diegosouzapw#3194) Integrated into release/v3.8.11
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…tion cooldown (diegosouzapw#3200) (diegosouzapw#3194) Integrated into release/v3.8.11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Test-only regression guard born from a TDD evaluation of the two combo-resilience PRs (#3145, #3169) against issue #3200 ("combos stay stuck on same-provider targets, never falling back").
Finding
The cascade #3200 describes is already prevented by the existing connection-cooldown. A real chat-pipeline test (seed openai + claude, a combo with 3 openai targets + 1 claude target, openai returning 404/5xx) shows:
markAccountUnavailablecools the connection down.openai/o1-mini,openai/gpt-4.1-mini) are pre-screened out before any dispatch ("no credentials available").openaiCalls === 1on the clean baseline — i.e. before either PR. This is stronger than PR #3145's provider-level counter (which would dispatch twice before short-circuiting) and needs neither PR #3169's parallel cooldown cache nor its rewrite ofcombo-provider-cooldown.test.ts.Change
Adds
tests/unit/combo-same-provider-cascade.test.tslocking in this behavior so a future change can't silently regress the cascade guard. No production code changed.Validated: passes on
release/v3.8.11baseline; the existing combo suite (combo-provider-cooldown,combo-routing-engine,combo-config— 97 tests) stays green.