[Rrainich]

What this fixes

DeepSeek often answers HTTP 200 with a business-level error (code=40003 INVALID_TOKEN, "messages too frequent", a killed web session) rather than a 4xx. The bridge indexed straight into data.biz_data on those responses, which raised TypeError: 'NoneType' object is not subscriptable inside the route. No status was attached, so the token-rotation path never fired — the dead token stayed pinned in the pool and every later turn failed the same way in ~330 ms until it was removed by hand.

Changes

functions.py

• UpstreamBizError(UpstreamError) + _biz_data() — one helper for data.biz_data. Auth-shaped business messages (login|auth|token|session|expire) map to 401 so the token is quarantined/rotated; everything else maps to 429 so it cools down and rotates. Because the status rides on UpstreamError, _upstream_http_code() and the existing 401/403/429 path in handle_chat pick it up unchanged.
• Replaced every raw ["biz_data"] index: create_challange_pow, create_new_chat, upload_file (×2), get_file_content (×2).

app.py

• _setup_failure_outcome / _setup_retry_kwargs — create_new_chat / create_challange_pow run before the try block that owns rotation, so an auth failure there escaped handle_chat as a bare 500 and the dead token was never marked. These now classify the failure, mark the token, and re-enter handle_chat with the failed token excluded — outside the per-signature asyncio.Lock, which is not reentrant (recursing inside it hung the request).
• POST /v1/messages/count_tokens (plus the /messages/count_tokens alias) — the route did not exist, so every Claude Code context probe was a 404.
• _with_deadline — the shared ClientSession uses ClientTimeout(total=None, connect=15, sock_read=600), and sock_read resets on every keepalive byte, so a slowly-dripping upstream never tripped anything (the access log has 19.7-minute /v1/messages entries). This puts a configurable ceiling (DEEPSEEKER_REQUEST_DEADLINE, default 600 s) on upstream work and raises UpstreamError(504). Scope note: it is applied inside the SSE generators because they outlive handle_chat's return. It covers "upstream goes silent" and cancels the upstream generator; a slow client still surfaces as CancelledError rather than a 504, so it is not an end-to-end hard ceiling.
• _is_truncated_stream_error — upstream hang-ups mid-stream (aiohttp.ClientPayloadError / TransferEncodingError) logged a full traceback and left the client on a dead socket. Downgraded to a warning; the terminal error frame still goes out.

Tests

• tests/test_upstream_hardening.py — 15 cases: count_tokens auth + flattening, _biz_data status mapping, deadline pass-through / 504 on hang / no deadlock on early abort, truncation detection.
• tests/test_setup_retry.py — 2 cases: a 401 on create_new_chat rotates and succeeds instead of 500-ing, and the retry does not deadlock on the signature lock.

274 passed in 16.08s

Behaviour change to be aware of

A flagged/invalid token now produces an honest 401/429 and rotation instead of a wall of 500s. That is recovery, not repair: if every token belongs to the same flagged account, rotation has nowhere to go and the client sees a 429. That is the correct signal — the previous 500 loop was hiding it.

Not covered

• The rotation path itself has no live test against a genuinely flagged upstream account; it is covered at the unit level only.
• hardening-backup.patch in my working tree is a local rollback artifact and is not part of this PR.

[1515asd]

Hi @Rrainich — thanks for this PR, the biz-error hardening is much needed. We just debugged a live incident tonight (2026-10-31 ~23:24 CST) that fits exactly the failure shape you describe (HTTP 200, ~330 ms instant failure), and we found the root cause. Sharing here since it interacts with this PR:

Upstream protocol change: parent_message_id: 0 is now rejected with biz_code 26 "invalid message id". The error arrives as application/json (not SSE), so the stream parser saw it as an empty stream — silent 502, no traceback, nothing actionable in logs. Notes:

• First message with parent_message_id: 0 → rejected on some edges; null was tolerated on some edges but not all (behavior varies per access point).
• Omitting the key entirely for the first message works everywhere; follow-up turns keep the existing parent = previous response id chain and are unaffected.

Fix verified live in our fork 1515asd/rh-deeperseeker (commit ac9a90f): omit the key for first message + empty-stream diagnostics that log response content-type and raw non-SSE body lines, so the next upstream protocol change is identifiable in logs within one request instead of an hour of guessing.

Your UpstreamBizError mapping would have made this visible immediately too — two complementary fixes for the same class of failure. Worth merging both. 👍