Repository navigation
Conversation
…ecolua#3729) When every model in a combo failed, the reply mixed two of them: lastError = errorText || String(result.status); // last failure if (!lastStatus) lastStatus = result.status; // first failure so a combo that ran out of models answered with, say, a 403 from the Console model tried first, carrying the text of the 429 the next model returned. That pair reads as one provider behaving incoherently, and is the shape reported in decolua#3729 as "403-wrapped-400". The report's diagnosis does not hold. checkFallbackError returns shouldFallback: true on every path, including its default, so no phrase list gates the advance; driving handleComboChat with a Console 403 followed by a working model does advance and return 200. Adding "Model is unavailable" to a match list would have changed nothing. What made fallback look broken was the error it produced after exhausting the list, which named a status and a message from different attempts. Status and message are now recorded together, so the client sees the failure that actually ended the combo. The thrown-exception path is paired the same way: it reports 500, and now carries the message that went with it. Verified with tests/unit/combo-failure-pairing.test.js (4 passed), which also pins that a Console 403 still falls through -- behaviour that already worked and should not be lost to a later change in the fallback rules. Restoring `if (!lastStatus)` fails exactly the pairing test. Pre-existing and untouched: combo-autoswitch.test.js fails 4 of 22 (detectRequiredCapabilities, reorderByCapabilities) on master with the same names.
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
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.
Addresses #3729.
The report's diagnosis does not hold
#3729 suggests the Console error is "not recognized by the fallback heuristic in
open-sse/services/accountFallback.js" and asks for the phrase to be added. ButcheckFallbackErrorreturnsshouldFallback: trueon every path, including its default:Driving
handleComboChatwith the exact reported failure confirms it — the combo advances:Adding
"Model is unavailable"to a match list would have changed nothing.What is actually wrong
When the list is exhausted, the reply mixes two different attempts:
Same probe, three models, all failing:
A 403 from the model tried first, carrying the text of a 429 from a later one. That reads as a single provider returning a nonsensical pair — which is exactly the
HTTP 403: [400]: {...}shape in the report, and why it looked like fallback had never run.The change
Status and message are recorded together, so the client sees the failure that actually ended the combo. The thrown-exception branch is paired the same way — it reports 500 and now carries the message that went with it.
Verification
tests/unit/combo-failure-pairing.test.js— 4 passed. Restoringif (!lastStatus)fails exactly the pairing test.One of those four pins that a Console 403 still falls through to a working model. That behaviour already works; the test is there so a later change to the fallback rules cannot quietly remove it.
Pre-existing, untouched:
combo-autoswitch.test.jsfails 4 of 22 onmaster(detectRequiredCapabilities > web_search tool -> search,reorderByCapabilities > keeps order when no model matches) — same test names with this change stashed, checked rather than assumed.This does not close #3729 by itself if the reporter's three models were all genuinely unavailable; it makes the failure legible so that case can be told apart from a broken fallback.