fix(llm-client): detect native sglang context-overflow messages - #426
fix(llm-client): detect native sglang context-overflow messages#426fparisio wants to merge 1 commit into
Conversation
Signed-off-by: Francesco Parisio <92143809+fparisio@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
WalkthroughThe backend adds two input-length phrases to OpenAI overflow detection. Regression tests cover native SGLang top-level errors for maximum-length and model-context-length rejections. ChangesOverflow detection
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change classifies two native SGLang context-overflow responses as typed context-window errors so fallback routing can work correctly. The change is localized and validated; no actionable merge-blocking risk remains. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
SGLang reports context-window overflows with wording that matches nothing in
OPENAI_OVERFLOW_PHRASES, so the failure is classified as a generic upstream 400 instead ofContextWindowExceeded, and context-window fallback routing never fires for SGLang backends.SGLang rejects an over-length request from two places. The KV-pool admission check in
srt/managers/utils.pyreturns:The declared-context check in
srt/managers/tokenizer_manager.py, hit when the server runs with an explicit--context-length, returns:The closest phrase in the list today is
exceeds the maximum allowed input length, the LiteLLM-wrapped variant, which differs from the first message by one word.This PR adds one phrase for each message. The wording is identical in v0.5.15.post1 and v0.5.17 (current latest), and SGLang's own test fixtures assert on "maximum allowed length", so a silent rewording upstream is unlikely.
The first test fixture is a verbatim capture from a live deployment. Both fixtures use SGLang's top-level
{"object":"error",...}envelope with noerrorkey, so they also cover the raw-body fallback inis_overflow_body.Validation:
cargo test -p switchyard-llm-client: 56 passedcargo test --workspacepasses;cargo fmt --checkandcargo clippyare cleancontext_length_exceeded; before the patch it returned the SGLang body wrapped as a generic upstream error.Summary by CodeRabbit