Repository navigation
fix(chatcore): report string-reason client aborts as 499, not 502 (#7907) - #8011
Conversation
…eaper-inference#7907) abort(reason) rejects the upstream fetch with the raw reason, which is often a bare string ("request_signal_aborted", "Client disconnected: ...") carrying no `name` or `status`. The chatCore catch block only recognized `error.name === "AbortError"`, so those aborts fell through to the 502 provider-failure default and were surfaced as `FAILED 502 / Bad Gateway` in the client response, request logs, and usage records. Classify the caught error with the existing isLocalStreamLifecycleError helper (expanded by cheaper-inference#7908 to cover AbortError plus the known abort reason strings) so every client-abort shape maps to `499 Request aborted`. Status-normalization follow-up to cheaper-inference#7908, which already excluded these aborts from provider circuit-breaker and cooldown accounting.
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Verified this against the current release tip: chatCore's failure-status mapping (lines ~3113-3157) still only checks |
|
Thanks for the review! One small note: the three PR workflows (Quality Gates, semgrep, DAST smoke) are still sitting in |
1699933
into
cheaper-inference:release/v3.8.49
…eaper-inference#7907) (cheaper-inference#8011) abort(reason) rejects the upstream fetch with the raw reason, which is often a bare string ("request_signal_aborted", "Client disconnected: ...") carrying no `name` or `status`. The chatCore catch block only recognized `error.name === "AbortError"`, so those aborts fell through to the 502 provider-failure default and were surfaced as `FAILED 502 / Bad Gateway` in the client response, request logs, and usage records. Classify the caught error with the existing isLocalStreamLifecycleError helper (expanded by cheaper-inference#7908 to cover AbortError plus the known abort reason strings) so every client-abort shape maps to `499 Request aborted`. Status-normalization follow-up to cheaper-inference#7908, which already excluded these aborts from provider circuit-breaker and cooldown accounting. Co-authored-by: xiaolong.835 <xiaolong.835@bytedance.com>
…eaper-inference#7907) (cheaper-inference#8011) abort(reason) rejects the upstream fetch with the raw reason, which is often a bare string ("request_signal_aborted", "Client disconnected: ...") carrying no `name` or `status`. The chatCore catch block only recognized `error.name === "AbortError"`, so those aborts fell through to the 502 provider-failure default and were surfaced as `FAILED 502 / Bad Gateway` in the client response, request logs, and usage records. Classify the caught error with the existing isLocalStreamLifecycleError helper (expanded by cheaper-inference#7908 to cover AbortError plus the known abort reason strings) so every client-abort shape maps to `499 Request aborted`. Status-normalization follow-up to cheaper-inference#7908, which already excluded these aborts from provider circuit-breaker and cooldown accounting. Co-authored-by: xiaolong.835 <xiaolong.835@bytedance.com>
Summary
Focused status-normalization follow-up to #7908 for #7907, as offered in the #7934 closing thread.
#7908 fixed the resilience side: client aborts no longer trip the provider circuit breaker or cool down healthy connections. What it intentionally left untouched is
chatCore's error surface — whenabort(reason)rejects the upstream fetch with a raw string reason ("request_signal_aborted"from streamHandler's default, or"Client disconnected: ..."), the string has noname/status, so the catch block'serror.name === "AbortError"check misses it and the abort falls through to the 502 provider-failure default. The client's own disconnect is then recorded asFAILED 502 / Bad Gatewayin the response body, request logs, and usage records.Change
open-sse/handlers/chatCore.ts: classify the caught error once with the existingisLocalStreamLifecycleErrorhelper (which fix(resilience): don't cool down accounts or trip the breaker on client aborts #7908 expanded to coverAbortErrorplus the known abort reason strings) and use that for the 499 status/message mapping and the early-return path. No new classifier is introduced.tests/unit/chatcore-translation-paths.test.ts: new integration testchatCore maps raw string abort reasons to 499, not 502 (#7907)— throws a bare"request_signal_aborted"string from the upstream fetch and assertsstatus: 499, error: "Request aborted".changelog.d/fixes/7907-chatcore-499-string-abort.md.Verification
release/v3.8.49(124557c, post-fix(resilience): don't cool down accounts or trip the breaker on client aborts #7908) the new test fails withactual: 502, expected: 499.tests/unit/chatcore-translation-paths.test.ts— 62/62 pass.circuit-breaker-abort-provider-trip-7907,circuit-breaker-client-abort,circuit-breaker-failure-kind,combo-499-abort,chatcore-compression-combo-predicates,proxyfetch-caller-abort-log-suppression— 30/30 pass.check:changelog-integrityOK; eslint on both touched files reports the same pre-existing count as base (no new findings).Refs #7907. Follow-up to #7908; supersedes the telemetry half of the closed #7934.