MALFORMED_RESPONSE "DeepSeek Messages SSE event type mismatch" hard-fails every in-flight turn in synchronized waves

[danieledwards2030-hue]

Environment: dsh 0.2.0-rc.2 (@deepseek-ai/dsh), Node v26.11.1, macOS arm64.
~12 concurrent agent sessions talking to the DeepSeek Messages endpoint.

What happened: twice in one evening, every session with a request in flight was
killed at nearly the same instant. Each turn ended with the same error:

{"kind":"error","error":{"message":"DeepSeek Messages SSE event type mismatch",
"code":"MALFORMED_RESPONSE"}}

Timestamps (UTC):
Wave 1: 2026-10-15T01:14:37Z - 01:14:59Z (7 of 7 live sessions)
Wave 2: 2026-10-15T01:30:03Z - 01:30:37Z (5 of 5 live sessions)
Both waves: synchronized across all streams, twice — 22-second fan-out, no
per-connection variation, including sessions idle between tool calls.

Where it throws (@deepseek-ai/dsh-llm-deepseek, lib/index.js; still identical in
0.2.1-alpha.3):

if (typeof event.type !== "string" || frame.event !== void 0 && frame.event !== event.type)
throw new LlmError("DeepSeek Messages SSE event type mismatch", "MALFORMED_RESPONSE");

Notes:

• Not rate limiting (no 429/quota), not a timeout/reset, not an HTTP 5xx.
• Separately, five scattered single-session failures the same day carried
  {"message":"DeepSeek Messages transport failed","code":"TRANSPORT"}; possibly
  unrelated, listed for completeness.

Asks:

1. Any idea what emits a frame whose event: disagrees with the JSON type
   here (proxy/LB frame injection, upstream stream merge)? The synchronized
   fan-out suggests a server-side stream fault.
2. Could the parser tolerate unknown/mismatched event types (skip + log) instead
   of failing the whole turn — or at least classify this as retryable?
3. Could the error include the offending raw frame? Right now the client-side
   classification is all we have to diagnose with.

Suggested fix (non-maintainer suggestion, from reading the current parser):

Keep MALFORMED_RESPONSE for genuinely unparseable frames only, treat the JSON
body's type as authoritative over the frame's event: name, skip unknown
event types with a log line, and include the raw frame in any error you do raise.

  const event = object(raw);
-if (typeof event.type !== "string" || frame.event !== void 0 && frame.event !== event.type)
-  throw new LlmError("DeepSeek Messages SSE event type mismatch", "MALFORMED_RESPONSE");
+if (typeof event.type !== "string") {
+  // genuinely malformed: keep the raw frame in the error for diagnosis
+  throw new LlmError(`DeepSeek Messages SSE frame missing type: ${frame.data}`, "MALFORMED_RESPONSE");
+}
+if (frame.event !== void 0 && frame.event !== event.type) {
+  // body is authoritative; a stray event: name is not worth failing the turn
+  console.warn(`DeepSeek Messages SSE event name mismatch (event=${frame.event}, type=${event.type}); continuing`);
+}
  if (event.type === "error") throw providerError(event, void 0);
+if (!KNOWN_EVENT_TYPES.has(event.type)) {
+  console.warn(`ignoring unknown DeepSeek Messages SSE event: ${event.type}`);
+  continue;
+}
  yield event;

If you prefer to keep failing on a frame/event mismatch, the minimum that would
help us: classify it as retryable (so the turn layer retries instead of ending
the turn) and include the offending frame.data in the error message.

Additional suggested code changes (same non-maintainer status; based on the
exports visible in the module — LlmError, RetryPolicySchema, resolveRetryPolicy):

1. Carry the offending frame at the throw site and let callers see it:

- throw new LlmError("DeepSeek Messages SSE event type mismatch", "MALFORMED_RESPONSE");
+ throw new LlmError(`DeepSeek Messages SSE event type mismatch: ${frame.data}`, "MALFORMED_RESPONSE");

2. Treat transient stream faults as retryable in the turn layer. Today both
   MALFORMED_RESPONSE and TRANSPORT end the turn, but both observed failure modes
   were transient server-side stream events — several attempts in our waves were
   killed while the session was idle between tool calls, and the next request on
   the same connection worked fine:

const TRANSIENT_STREAM_CODES = new Set(["MALFORMED_RESPONSE", "TRANSPORT"]);
// at the retry-policy resolution point (resolveRetryPolicy):
if (TRANSIENT_STREAM_CODES.has(err.code) && attempt < maxAttempts) {
  return scheduleRetry(backoff(attempt));
}

3. Consumer-side context: our UI (built on the harness) plans to show a turn
   ending in one of these codes as a plain, non-alarming error row with a Retry
   action, keeping the session usable. That is much easier to make honest if (1)
   and (2) exist upstream: our Retry button would simply re-issue the turn, rather
   than guessing whether the failure was stream breakage or a provider refusal.

[danieledwards2030-hue]

Evidence update — third wave, same code, with a clear timing signature.

Wave 3: 2026-10-15T01:38:39Z - 01:55:18Z, 7 of 7 live sessions, identical
MALFORMED_RESPONSE "DeepSeek Messages SSE event type mismatch".

New observation: the failures are locked to a ~15-minute streaming duration.
Measured from the start of the in-flight turn/request to the failure:

+15m02s, +15m03s, +15m03s, +15m07s, +15m03s (wave 3, five measured turns)
+15m09s, +15m01s .. +15m04s (wave 2, measured the same way)

That is 12 kills within 15m01s-15m09s of continuous streaming, and the waves
only looked "synchronized" because many sessions started requests together
after a bulk resume. This looks like a stream-duration cutoff (~15 min) on the
path (proxy/LB or server), after which the client sees a torn or truncated final
frame and the strict parser classifies it as MALFORMED_RESPONSE instead of a
timeout — which matches why the raw JSON in those frames could not be reported:
the frame that trips the check is likely the malformed tail of a torn stream.

This strengthens the suggested fix above: on frame.event !== event.type or a
non-string type, the likely truth is "the stream was torn", so a retryable
timeout/transport classification (and including frame.data in the message)
would both survive these incidents and make them diagnosable.

[danieledwards2030-hue]

One more data point, and it may tie the whole picture together: we just got a
plain provider 503 on a fresh request (a different failure mode from the
torn-stream MALFORMED_RESPONSE kills):

{"message":"Service is too busy. We advise users to temporarily switch to
alternative LLM API service providers. (request_id: 8b79906e-08a3-4da6-ab44-4461a17417ca)",
"code":"SERVER","status":503}

request_id 8b79906e-08a3-4da6-ab44-4461a17417ca at 2026-10-15T02:11:46Z, if
useful for tracing on your side.

Working hypothesis after 5 waves: the ~15-minute stream cutoff and the 503s
may share a root cause — capacity pressure/load shedding on the path. If long
streams are being torn to free capacity, the parser fix (classify torn/mismatched
frames as retryable, include frame.data) would turn both symptoms into successful
retries instead of dead turns.