DeepSeek Harness web panel hangs on keepAliveTimeout

A plugin panel that spins forever after a few idle seconds is not a broken frontend state machine; the request was written onto a keep-alive connection the server was closing. When dsh-host-webserver creates the HTTP server it sets neither keepAliveTimeout nor headersTimeout, so Node's 5-second idle default applies. If the browser reuses the connection right at that boundary, it hits a close/send race and the request neither returns nor reports an error (Discussion #10106).

DeepSeek Harness web hang: reproduce with an 8-second idle connection

A raw socket separates "the server is healthy" from "the browser hangs". The reproduction script in the thread makes two requests against the dsh web port:

import http.client, time
c = http.client.HTTPConnection('127.0.0.1', 3080, timeout=10)
c.request('GET', '/'); print(c.getresponse().status)
time.sleep(8)
c.request('GET', '/'); print(c.getresponse().status)

1. Send the first request and confirm a new connection returns 200 immediately. Expected: a normal status and the connection enters the keep-alive pool.
2. Sleep 8 seconds and reuse the same connection. Expected: a ConnectionResetError, or a wait until your own 10-second timeout.
3. Inspect the connection state with lsof -nP -iTCP:3080. Expected: CLOSE_WAIT, meaning the server has closed and the client has not noticed.
4. Request the same path on a brand-new connection. Expected: immediate success, proving the server itself is not stuck.

Step 4 is the decisive check: new connections always work, and only reused idle connections hang. That places the fault in the connection layer, not in application code.

DeepSeek Harness correction: the browser is not unaware

Permanent loading is not caused by the client failing to know the connection is closing; it is caused by the close and the send landing at the same instant. Replies in the thread clarify two points:

1. Node sends Keep-Alive: timeout=5 on every keep-alive response, and Chrome, Firefox, and Safari all use it to evict idle sockets early, so the browser is not blind.
2. What produces "the promise never settles" is the close/send race: the client writes just as the server timer fires, the bytes are accepted by a connection being dismantled, and no response is generated, so the client waits for its own timeout.
3. The fix is still to set the timeouts, but they must satisfy headersTimeout > keepAliveTimeout. Node does not enforce the relation; the semantics do.
4. Compression is not a host default: DEFAULT_COMPRESSION is none, and gzip is enabled at the bundle layer, so changing the timeouts does not interact with compression.

That also explains why a refresh helps: it opens a new connection and bypasses the socket that is dying.

These clarifications do not change the fix but they do change verification. Do not decide the fix worked by whether the client shows a timeout; check whether a reused idle connection still gets a complete response. A client-side error only means the client reached its own deadline and says nothing about connection health.

DSH plugin path 1: set both timeouts on the server

This is the only root fix, and both values must be set together with the header timeout larger. Add them after createServer and before listen:

server.keepAliveTimeout = 60_000;
server.headersTimeout = 65_000; // must exceed keepAliveTimeout

1. Confirm that a repository-wide search finds neither setting in the current host version. Expected: zero hits for keepAliveTimeout and headersTimeout, which shows Node defaults are in use.
2. Add the two assignments where the webserver creates its server instance. Expected: the service starts normally with no parameter errors.
3. Restart dsh web and repeat the 8-second idle reuse test. Expected: the second request returns 200 instead of resetting or hanging.
4. Leave the page untouched for 30 seconds, then open a plugin panel. Expected: the panel loads without a refresh.

If your host version already exposes these values as configuration, change the configuration instead of the source; the test is whether the config schema defines the fields.

DeepSeek Harness path 2: client timeout plus one retry

This suits plugin authors as a temporary stopgap and should not be treated as a fix. The reporter added a 10-second AbortSignal.timeout and one automatic retry to their plugin; it does self-heal, but each occurrence wastes 10 to 20 seconds. If you write panel plugins, compare how others handle timeouts on DSH Plugin Hub:

1. Add a 10-second AbortSignal.timeout to the panel's fetch calls. Expected: a hang no longer lasts indefinitely and throws a timeout error after 10 seconds.
2. On timeout, retry once on a new connection, and only for idempotent requests. Expected: the panel eventually loads, with a visibly slower first paint.
3. Log the URL and elapsed time before retrying. Expected: you can measure how long recovery takes after each idle period and decide whether the stopgap is worth keeping.

Do not auto-retry non-idempotent plugin RPCs, or you may duplicate writes. Once the server is fixed, remove this layer rather than leaving both in place.

Keep retries to one or two. Every retry opens a new connection, so more attempts turn a 10-second hang into a 30-second wait and hide the fact that the server timeouts are unset.

DeepSeek Harness path 3: align the reverse proxy idle timeout

When dsh web sits behind nginx, Caddy, or a corporate gateway, the proxy recycles connections before the host does. Set the upstream idle time longer than the proxy's own:

1. Read the proxy's idle settings: keepalive_timeout and proxy_read_timeout for nginx, the timeouts block for Caddy. Expected: concrete seconds to compare with the new host values.
2. Set the upstream connection idle timeout above the host's keepAliveTimeout and make sure HTTP/1.1 upstream connections are used. Expected: proxy_http_version 1.1 takes effect and the Connection header is no longer forced to close.
3. Reload the proxy configuration and repeat the idle reuse test. Expected: requests through the proxy no longer hang.
4. If the proxy cannot be changed, lower the host's keepAliveTimeout below the proxy threshold instead. Expected: the host closes first, so the proxy does not forward a half-dead connection upstream.

The common mistake here is changing the host and not the proxy, which moves the symptom from "hangs after 5 seconds" to "hangs after 60 seconds". It looks fixed, but the boundary only moved.

DeepSeek Harness: how to confirm the fix

There is one acceptance criterion: after idling past the old threshold, a reused connection still gets a complete response. Check in order:

1. Run the raw socket script with 6, 30, and 55 seconds of idle time. Expected: all three return 200; success at 55 seconds shows the new idle threshold covers the full 60 seconds.
2. Open the browser developer tools Network panel and watch the first request after an idle period. Expected: status 200, with no (failed) and no long pending state.
3. Check the server for accumulated CLOSE_WAIT sockets. Expected: the count stays stable and does not grow with page idle time.
4. Run curl --no-keepalive against the panel endpoints repeatedly. Expected: every request uses a new connection and succeeds, which further isolates the problem to connection reuse.

Two easy misreads to keep in mind: the browser does know the connection may expire, because Keep-Alive: timeout=5 is in every response; and gzip is not slowing the response, because host compression defaults to none and bundle-level gzip is unrelated to the timeout.

According to the thread, the defect is still unfixed on the host side, and the reporter's in-plugin patch works, which confirms the diagnosis. Do not confuse it with gzip stream buffering: that stalls a response in the zlib buffer after it has been written, producing a stuttering render rather than permanent loading.

Source: Discussion #10106, deepseek-ai/deepseek-harness. For web auth and port issues, see DSH web auth and port.