DeepSeek Harness messages transport failed: three checks

DeepSeek Harness began returning messages transport failed every afternoon, always on long answers and never on the first message of a session. The error survived two reinstalls and sent us toward the wrong layer for most of a week. The record below covers the proxy, certificate and SSE evidence, plus the cause that finally held.

The DeepSeek Harness messages transport failed symptom

The failure looked like a model stall, but the pattern was too regular to be a model problem.

A typical session started cleanly, streamed a few hundred tokens and then stopped without a business error code. The interface showed the transport message and offered a retry, which usually worked for a short prompt and failed again on a long one. Nobody in the office could reproduce it from home, and the timing clustered around the afternoon peak. The model provider dashboard showed no corresponding incident.

We initially treated the afternoon pattern as load, because that was the simplest story. The same request at nine in the morning finished, and the same request at three in the afternoon died near the same token count. That consistency was the first clue that a fixed timeout, not traffic, was shaping the result. It also meant our reproduction needed to keep the request long enough to cross that boundary.

The wrong assumptions we made about DeepSeek Harness

We spent two days on assumptions that felt reasonable and were all wrong.

The first assumption was that a reinstall would reset whatever state had gone bad. It did not, because the failure lived outside the installed package and survived a clean profile. The second was that raising the client timeout would help, and it did for a few days before the same cut returned. Both moves changed the surface without touching the network path.

The third assumption was that DSH plugins were involved, since a DeepSeek Harness plugin had been updated the week before. We checked the entries in the DSH Plugin Hub and compared the declared versions, but the failure persisted with the plugin disabled. That ruled out the plugin runtime without ruling out the transport. The model provider was the last suspect, and it too was innocent.

Evidence from the DeepSeek Harness proxy layer

The proxy turned out to be the first place that produced evidence we could act on.

The office used an inspection proxy that terminated TLS, rebuilt connections and applied a sixty-second idle timeout. Its allowlist included the API host and port, which is why early requests succeeded and the allowlist check looked clean. The proxy logs, however, showed the connection closing at almost exactly sixty seconds during long responses. That was more specific than anything the client had reported.

We bypassed the proxy once from the same machine and the long answer completed. That did not prove the proxy was the only cause, but it moved it from theory to variable. The logs also showed the response arriving in a single burst rather than as a stream of events. Buffering was now a concrete observation, not a guess.

Evidence from the DeepSeek Harness certificate layer

The certificate chain was healthy, which was useful mainly because it removed a dramatic theory.

The inspection proxy replaced the upstream certificate with an enterprise one, and the runtime initially did not trust the issuing root. We imported the root into the trust store and confirmed the chain, including the intermediate, with a direct TLS request. After that, handshakes succeeded consistently and the client stopped reporting certificate errors. The remaining failure was clearly something else.

This step mattered because disabling verification would have hidden a real problem while making the symptom look solved. We kept verification on and treated the trust-store change as a separate fix. If the chain had still been broken, the transport message would have been a symptom of TLS rather than streaming. The evidence said otherwise, so we moved on.

Evidence from the DeepSeek Harness SSE layer

The SSE layer explained the shape of the failure: short answers passed and long answers died.

We compared short and long prompts against the same endpoint and watched the timing. The short answer completed before the proxy timeout and arrived normally. The long answer produced no incremental events, then failed when the proxy closed the connection. The server had generated output, but the client never received it as a stream.

That difference pointed to buffering rather than generation. A proxy that accumulates an event stream can look healthy in request logs while giving the client nothing until the connection ends. When the connection ends early, the client reports a transport failure with no model reply to read. The table below is the evidence that separated these cases.

The cause of messages transport failed in DeepSeek Harness

The final cause was a proxy policy that buffered server-sent events and closed long streams at sixty seconds.

The proxy could inspect the API host, but its streaming policy was never enabled for that destination. It held events until a buffer threshold or the idle timeout, then tore down the connection. Short answers finished before either limit, which made the problem look intermittent. The client reported a transport failure because no complete stream ever arrived.

The fix was a proxy rule that passed SSE without buffering and allowed a longer idle period for that endpoint. We kept certificate verification on and did not raise client timeouts as a substitute. The verification we ran afterward was deliberately narrow:

1. Send a short prompt and a long prompt on the office network and compare completion.
2. Repeat both with the proxy bypassed to confirm the network variable.
3. Confirm the enterprise root is trusted and the full chain validates.
4. Ask the network team to show the streaming policy for the API destination.
5. Keep the ticket open for a week and check the afternoon peak specifically.

After the rule changed, long prompts streamed the way they did at home. The afternoon pattern disappeared, and the client stopped producing the transport message. We kept the certificate fix because it addressed a real trust gap, even though it was not the cause. The incident closed with one proxy policy and one corrected assumption.

Sources: npm logging docs, DeepSeek Harness quickstart, deepseek-harness repository.