[Provider compatibility] DeepSeek V4 Flash Responses 502 needs v2.11+ reproduction #1176

Area

Provider compatibility / DeepSeek Responses streaming

Current status

This issue originally reported a local HTTP 502 when Codex Responses requests were routed to:

deepseek/deepseek-v4-flash

on OpenCodex 2.10.2.

The historical failure looked like:

status: 502
errorCode: upstream_server_error
closeReason: non_stream
upstreamError: upstream JSON response stalled before completing
usageStatus: unreported
durationMs: 90241
inboundProtocol: responses
requestedModel: deepseek/deepseek-v4-flash
requestedEffort: max

That report was valid for the 2.10.x transport behavior.

However, the DeepSeek Responses transport changed in v2.11.0.

Commit:

0b8e608c

removed the DeepSeek-specific bounded-JSON force and restored live upstream Responses streaming after fresh live probes showed that deepseek-v4-flash now emits valid terminal events and closes correctly.

This issue therefore now tracks whether the original 502 still reproduces on the current streaming path.

Historical 2.10.x behavior

On 2.10.2, DeepSeek V4 Flash Responses traffic could be forced through a bounded non-stream JSON read.

The relevant timeout policy included:

• total / first-byte bounds;
• an inter-chunk inactivity bound;
• conversion of an incomplete bounded body read into a local upstream error.

The reported request failed after roughly:

90 seconds

which was consistent with an inter-chunk inactivity timeout occurring after some response data had already arrived.

At that point three possibilities remained:

1. DeepSeek legitimately paused longer than the inactivity deadline.
2. The bounded-JSON transport was inappropriate for this model.
3. The upstream genuinely stalled and OpenCodex correctly terminated it.

There was not enough evidence to safely distinguish those cases.

What changed in v2.11.0

Fresh live DeepSeek probes showed that the current Responses endpoint emits valid terminal events:

response.completed
response.incomplete
response.failed

and that the connection closes normally after the terminal event.

The OpenCodex relay already treats those terminal events as the protocol boundary and can synthesize the downstream [DONE] sentinel when required.

As a result, the DeepSeek registry entry no longer forces:

stream: false

for deepseek-v4-flash.

Current requests use the real upstream SSE stream instead.

The old bounded-JSON timeout analysis should therefore no longer be treated as the current root cause.

Current reproduction needed

Please repeat the original workload against:

OpenCodex v2.11.0+

or current dev.

Use:

• Codex App/Desktop;
• built-in deepseek provider;
• deepseek-v4-flash;
• Responses inbound protocol;
• a sufficiently long or tool-oriented request;
• the same reasoning effort if possible.

Expected behavior

The request should:

1. receive incremental upstream Responses events;
2. continue through long model generation without being converted into the historical bounded-body 502;
3. receive a valid terminal event;
4. complete normally in Codex;
5. report usage normally.

If the 502 still reproduces

Please capture:

1. exact OpenCodex version or commit;
2. Codex App/Desktop version;
3. request ID;
4. requested model and reasoning effort;
5. whether any response deltas arrived before failure;
6. the last upstream SSE event received;
7. the exact OpenCodex error payload;
8. total request duration.

Prompt contents and credentials can be removed.

The important evidence is the stream lifecycle immediately before the 502.

How to interpret a current failure

No upstream bytes arrive

This points toward:

• connectivity;
• first-byte timeout;
• provider availability;
• authentication;
• or another pre-stream failure.

That is different from the historical inter-chunk body stall.

Streaming begins, then stops before a terminal event

This would establish a current upstream or relay streaming stall.

Capture the final event and timing gap.

A valid terminal event arrives but OpenCodex still returns 502

This would establish a current relay/terminal handling bug.

That would be directly actionable in OpenCodex.

Request succeeds on v2.11+

The original 2.10.2 failure no longer reproduces and the issue can be closed as resolved by the transport changes that restored live DeepSeek Responses streaming.

Unrelated reports

A generic:

Provider unreachable: Unable to connect

failure against another provider/model is not the same bug.

This issue is specifically about:

deepseek-v4-flash
Responses
stream lifecycle / local 502

and should not become a catch-all for unrelated upstream_server_error responses.

Relationship to #1128

#1128 concerns remote auto-compaction.

This issue concerns ordinary Responses turns.

They share the DeepSeek transport surface but use different request paths and should remain separate.

Acceptance / closure criteria

Close this issue if the original workload succeeds on v2.11+ and the historical 502 can no longer be reproduced.

Keep it open if a current reproduction shows:

• a stream that stalls before its terminal event; or
• a valid terminal event that OpenCodex mishandles.

Any current failure should be investigated from the captured SSE lifecycle rather than restoring the obsolete 2.10.x bounded-JSON force.

Checks

• Historical 2.10.2 failure is preserved.
• The old bounded-JSON transport is marked historical.
• The v2.11.0 streaming restoration is documented.
• Unrelated provider-connectivity failures are excluded from scope.
• Original workload retested on v2.11.0+ or current dev.