[Bug] llm-deepseek: SSE keep-alives re-arm the idle watchdog forever — a 300s idle timeout actually waited 17.7 min, and a chatty provider can hang a turn unboundedly

[zhiyuchen1101]

Summary

llm-deepseek (chat-completions protocol) can receive a complete assistant
message — reasoning and tool-call blocks included — yet never receive a terminal
event from the provider. The connection stays open and keeps emitting SSE
comment lines. Because onActivity → watchdog.pulse() re-arms the idle timer
on every comment line, the configured streamIdleTimeoutMs does not bound
the wait.

Two distinct consequences:

1. The failure text does not match reality. It reads
   DeepSeek stream idle timeout after 300000ms, but the measured wait was
   10.0 / 17.3 / 17.7 minutes across three attempts.
2. The wait is unbounded in principle. A provider that keeps emitting
   keep-alives without ever terminating can hold one attempt open indefinitely;
   no configuration value bounds it, in either direction.

Environment

• macOS (Apple Silicon); @deepseek-ai/dsh@0.1.5-rc.1
• provider deepseek-official, model deepseek-v4-flash
• baseURL: https://api.deepseek.com/beta, protocol left at its default (chat-completions)
• reasoningEffort: max, maxTokens: 256000, streamIdleTimeoutMs: 300000
• session context ≈ 190k tokens (cacheReadTokens ≈ 180k)

Observed stream, in order

[+ 0.00 min] chunk block-start      blockType=reasoning
[+ 0.00 min] run   reasoning-chunks   1560 members, span 0.12 min
[+ 0.05 min] chunk block-start      blockType=tool-call
[+ 0.05 min] run   tool-call-chunks   1169 members, span 0.14 min
[+17.39 min] chunk finish           {kind: "error", failure: {code: "TIMEOUT"}}

The trailing finish is a local synthesis — its reason carries the timeout
error — not a provider event. In the same session, every successful request
instead ends with finish {kind: "tool-calls"} or {kind: "stop"} at
0.00 min after the last content record.

Three consecutive attempts on the same step, all TIMEOUT, all with the
payload fully delivered before the hang:

• retry 1/5 — 10.02 min of silence after the last content record
• retry 2/5 — 17.34 min
• retry 1/5 (next step) — 17.70 min

User-visible effect: a turn that produced no output for ~59 minutes, then failed.
The retry delay itself was only 475–999 ms, so essentially all of the wait was
the hang.

Why streamIdleTimeoutMs does not bound it

packages/util/timeout/src/index.ts:

next<T>(iterator) { outstanding = true; arm(); /* ... */ }
pulse(): void {
  if (disposed || !outstanding) return
  arm()               // re-arms from now, it does not accumulate
}

packages/llm/llm-deepseek/src/protocols/chat-completions/adapter.ts:211 passes
() => { watchdog.pulse() } as onActivity, and sse.ts documents that
callback as "optional transport-activity callback; comments never enter the
yielded payload stream".

So every SSE comment line resets the timer. streamIdleTimeoutMs is therefore a
keep-alive-silence timeout, not a ceiling on how long an attempt may hang:

• raising it strictly makes the failure later;
• lowering it does not help while the keep-alive interval stays below it.

Related

• [Bug] OpenAI Responses final item completes but missing response.completed hangs until idle timeout #6594 — same class of defect on a different adapter (llm-pi-ai /
  openai-responses): final answer item complete, response.completed missing,
  hangs until the idle timeout. This report adds an independent reproduction on
  llm-deepseek / chat-completions, where the reasoning text and the tool
  calls are both complete.
• Bug: LLM requests die at ~302s with `terminated` when a provider needs >5min silent prefill #5673 — different mechanism (undici bodyTimeout/headersTimeout killing a
  silent prefill before the first byte). Not this.

Expected behavior

1. An absolute per-attempt ceiling that keep-alive traffic cannot extend (e.g. a
   separate streamMaxDurationMs), reported with the value actually elapsed.
2. The timeout message should name the measured silence / elapsed duration, not
   only the configured threshold.
3. Ideally, a bounded grace path once a complete assistant payload has arrived,
   as [Bug] OpenAI Responses final item completes but missing response.completed hangs until idle timeout #6594 proposes (terminalEventGraceMs).

Raw session transcript (zstd jsonl) and the extraction script are available on
request.

[argszero]

A plugin now covers the two bounds this asks for, mountable without touching the adapter:

@argszero/cordis-plugin-stream-ceiling@0.1.0

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-stream-ceiling
• source: https://github.com/argszero/cordis-plugin-stream-ceiling

dsh plugin add @argszero/cordis-plugin-stream-ceiling

It hooks the public llm/stream waterfall, so every bound it applies is defined on the payload stream a consumer can actually see. SSE comments never enter that stream, which makes the re-arming mechanism unreproducible here by construction — no in-band traffic can extend a bound.

option	measures	default
maxStalledMs	silence between payload chunks (and time-to-first-chunk)	600000
maxCallMs	the whole call, chunk deliveries included	0 (off)
payloadGraceMs	silence after the payload has closed while the provider still owes a terminal event	0 (off)
code	failure code on the terminal error finish	TIMEOUT
skipPurposes	auxiliary call purposes exempted from every bound	[]

When a bound elapses the call ends with one terminal finish whose message names the duration actually measured beside the bound it breached — the second half of your report:

stream-ceiling: no model output for 1062000ms (maxStalledMs 300000ms; 14 chunk(s) received, last "reasoning-delta") — transport keep-alives cannot extend this bound
stream-ceiling: no terminal event for 61500ms after the payload closed (payloadGraceMs 60000ms; 3 chunk(s) received, last "block-end")

Mapping to your three expectations:

1. An absolute per-attempt ceiling → maxCallMs.
2. The message names the elapsed duration → always, for every bound.
3. A bounded grace path once a complete payload has arrived → payloadGraceMs. It is off by default because how long a provider legitimately pauses between blocks is provider behavior rather than an error, but it is exactly your stream shape: with payloadGraceMs: 60000, all three of the attempts you measured would have ended at ~1 minute with the payload intact, instead of 10.0 / 17.3 / 17.7 minutes.

- set:
    - id: stream-ceiling
      config:
        payloadGraceMs: 60000

Two things it deliberately does not do, so the adapter-side fix stays on the table:

• It cannot abort the socket. GenerateOptions.signal is a read-only AbortSignal (no abort()), and an async generator queues return() behind an outstanding read, so abandoning the upstream iterator cannot interrupt the provider's parked read either. The plugin ends the call — which is what the loop, the retry policy and the user observe — while the socket is released by the adapter's own read settling or the request context being torn down.
• onActivity still pulses on comments, so streamIdleTimeoutMs keeps its current "keep-alive-silence" meaning; this plugin does not change it.

One caveat worth knowing when choosing code: TIMEOUT is inside RetryPolicySchema's default retryableCodes, so a trip costs one attempt rather than the turn. Set a code outside that list (e.g. STREAM_CEILING) to fail the call outright instead — that gives up the attempt's output but stops a provider that hangs on every attempt.

Verified with 18 tests (npm test), including an end-to-end run through a real cordis Context and llm/stream waterfall, and a simulation where 500 keep-alive pulses cannot re-arm a bound.