DeepSeek Harness v0.1.2-alpha.2: Connection Recovery Becomes Visible
Source-backed notes on DSH v0.1.2-alpha.2: visible disconnect states, automatic retry, manual reconnect, 2-second heartbeat checks and how to verify recovery behavior.
On this page
v0.1.2-alpha.2 is not the current source snapshot. DeepSeekDSH currently verifies 0.1.2-alpha.5; this page preserves what alpha.2 introduced and how the implementation worked at that release boundary.
Release fact
DeepSeek published v0.1.2-alpha.2 on August 30, 2026 at 13:52:14 UTC. The official release notes list a new Web UI connection-error state with automatic retry and immediate reconnect support.
Why this matters for long-running agents
A short command can simply fail and be retried. A remote gateway, persistent Agent or long Web session can sit in an ambiguous state where users cannot tell whether the model is still working, the network is backing off, or the transport is dead. Alpha.2 turns that ambiguity into an observable connection lifecycle that users can watch and interrupt.
The Web UI exposes three recovery phases
Disconnected
A warning indicator appears near Settings instead of leaving the user with a silent or ambiguous failure.
Connecting
Automatic retry remains visible while the connection layer is attempting recovery. Hovering or focusing exposes the reconnect action.
Recovered
After a disconnected/connecting state returns to connected, the UI shows a success confirmation for 2,000 ms before returning to the normal state.
What the source actually changed
The user-facing indicator and the transport recovery logic landed in separate commits. Reading both is important: one explains what the user sees, the other explains who owns retry timing and physical socket replacement.
The 2-second heartbeat does not mean DSH retries every two seconds. Heartbeat/liveness checks and retry backoff are separate mechanisms: the connection controller still owns progressive retry timing, while heartbeat detects dead physical connections faster.
How to verify alpha.2 recovery behavior
- 01
Start a remote or long-running Web session
Use a session where losing the transport would otherwise be easy to confuse with a slow model response.
- 02
Interrupt the network temporarily
Confirm that a visible disconnected/connecting state appears instead of relying on a blank or apparently frozen interface.
- 03
Restore the network
Watch automatic retry recover the connection and confirm the short recovered-success state is shown.
- 04
Test manual reconnect during backoff
While the connection is waiting or attempting recovery, use the reconnect control and confirm it interrupts the current attempt/delay and starts a fresh connection attempt.
The recovery path kept evolving after alpha.2
Alpha.3 specifically fixed backend stalls being mistaken for network disconnections. That follow-up matters because alpha.2 made connection state visible; alpha.3 then reduced one source of false-positive disconnects. Alpha.4 added further agent and long-session changes, and alpha.5 is the latest verified source snapshot at the time this page was updated.