DeepSeek V4 Flash returns local 502 after 30s on bounded JSON path (post-#1026)

[simon1561]

Client or integration

Codex App

Provider or upstream service

DeepSeek API

OpenCodex version

2.10.1 (npm latest; includes #1026)

Endpoint or capability

DeepSeek V4 Flash Responses API / bounded non-streaming JSON fallback

Current behaviour

After upgrading to OpenCodex 2.10.1, DeepSeek V4 Flash requests intermittently fail with a local HTTP 502 after approximately 30 seconds.

The affected request log entries are consistently:

status=502
errorCode=upstream_server_error
closeReason=non_stream
upstreamError=upstream JSON response stalled before completing
durationMs=approximately 30500-31300
provider=deepseek
model=deepseek-v4-flash

This occurs with both the high and max reasoning efforts. In one local session, successful requests and these 502 failures coexist; this does not look like an API-key failure or a service crash.

Minimal redacted reproduction

1. Run OpenCodex 2.10.1 on macOS.
2. Configure the built-in DeepSeek provider with model deepseek-v4-flash.
3. Use the Codex App and send a normal coding request with thinking enabled; tool use or a longer multi-turn context makes the failure easier to observe.
4. Repeat with reasoning effort high and max.

No API key or private prompt is included in this report.

Actual response or error

OpenCodex returns:

502 upstream_error
upstream JSON response stalled before completing

The failure is generated by OpenCodex's bounded JSON body reader, not necessarily an HTTP 502 returned by DeepSeek itself.

Expected behaviour

A valid DeepSeek response should either:

• complete successfully when the upstream eventually returns a valid JSON body; or
• use a reliable upstream streaming path with correct Responses terminal/tool-call events.

At minimum, the inactivity deadline should be provider/model-specific or configurable so that normal V4 Flash reasoning latency is not converted into a misleading local 502.

Relevant implementation context

PR #1026 intentionally changed DeepSeek V4 Flash to bounded JSON upstream and synthesizes terminal SSE events for Codex clients:

#1026

The current implementation has a 180-second total body limit but a 30-second body inactivity limit:

https://github.com/lidge-jun/opencodex/blob/v2.10.1/src/server/responses/core.ts#L748-L753

The 502 is emitted when that inactivity limit is reached:

https://github.com/lidge-jun/opencodex/blob/v2.10.1/src/server/responses/core.ts#L2227-L2239

This appears distinct from the original post-tool-call terminal-event issue tracked in #875, which #1026 addressed:

#875

Upstream documentation

• DeepSeek Responses API reference: https://api-docs.deepseek.com/api/create-response/
• DeepSeek thinking mode and tool-call continuation requirements: https://api-docs.deepseek.com/guides/thinking_mode/

The public specification documents both stream:true semantic SSE with a terminal response.completed/response.incomplete/response.failed event and the need to preserve reasoning content across tool-call follow-ups. It does not specify a maximum 30-second first/body-chunk latency for non-streaming V4 Flash requests.

Suggested investigation

1. Compare DeepSeek V4 Flash stream:false and native Responses stream:true under the same payload and reasoning effort.
2. Confirm whether a 30-second no-body interval is expected for V4 Flash thinking/tool requests.
3. If native streaming now terminates correctly, consider restoring it behind a provider capability flag with terminal-event repair.
4. Otherwise, make the bounded-JSON inactivity timeout provider/model-specific and preserve the existing item-id, reasoning, and tool-call repairs.
5. Add a regression test for a valid JSON response whose first/body chunks are delayed for more than 30 seconds.

Checks

• Existing issue search completed.
• This report is separate from [Bug] DeepSeek V4 Flash Responses route stalls after tool calls #875: [Bug] DeepSeek V4 Flash Responses route stalls after tool calls #875 covered post-tool-call continuation/terminal handling; this report covers the 30-second bounded-JSON inactivity failure after fix(deepseek): transport-neutral bounded-JSON policy with terminal SSE synthesis (#875) #1026.
• Request and response details are redacted.
• The report includes exact version, model, effort levels, timing, and error text.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[lidge-jun]

Fixed on dev by PR #1088, merge commit 4db2eb3. Root cause: the bounded JSON reader armed its 30s inactivity timer before the first body byte, so a DeepSeek V4 Flash turn thinking >30s after early chunked headers died locally with exactly the reported 502 at ~30.5s. The bounded read now has a separate first-byte deadline (the existing 180s total budget) while keeping 30s inter-chunk stall protection. Thank you for the precise log fields — durationMs 30500-31300 was the confirming signature. Ships with the next release train.