Describe the bug
When using the deepseek-v4-flash model via the Anthropic-compatible endpoint, the DeepSeek API sometimes returns a response with Content-Type: text/html; charset=utf-8 instead of the expected text/event-stream or application/json.
The error observed:
model provider error.; anthropic stream error for model deepseek-v4-flash: invalid header value: "text/html; charset=utf-8"
debug=InvalidContentType("text/html; charset=utf-8", Response { url: "https://api.deepseek.com/anthropic/v1/messages", status: 200, headers: { "content-type": "text/html; charset=utf-8", ... } })
Current behavior
This error is classified as a provider error but is not being auto-retried. The error falls through to the user as a failure rather than being caught by the retry mechanism.
Root cause
The invalid header value error may not be correctly classified by the classify_error() function in crates/core/src/query.rs. It likely doesn't match any of the existing ProviderError variants and falls into the generic UnknownError path, which only retries for 408/500-599 status codes. Since the HTTP status is 200, it gets classified as unretryable.
Expected behavior
This type of stream/protocol error should be retried (it's a transient API issue). It should be classified as a NetworkError or similar retryable class.
Where to look
crates/core/src/query.rs:217-310 — classify_error() function
- Provider stream parsing code that produces this error
Describe the bug
When using the
deepseek-v4-flashmodel via the Anthropic-compatible endpoint, the DeepSeek API sometimes returns a response withContent-Type: text/html; charset=utf-8instead of the expectedtext/event-streamorapplication/json.The error observed:
Current behavior
This error is classified as a provider error but is not being auto-retried. The error falls through to the user as a failure rather than being caught by the retry mechanism.
Root cause
The
invalid header valueerror may not be correctly classified by theclassify_error()function incrates/core/src/query.rs. It likely doesn't match any of the existingProviderErrorvariants and falls into the genericUnknownErrorpath, which only retries for 408/500-599 status codes. Since the HTTP status is 200, it gets classified as unretryable.Expected behavior
This type of stream/protocol error should be retried (it's a transient API issue). It should be classified as a
NetworkErroror similar retryable class.Where to look
crates/core/src/query.rs:217-310—classify_error()function