Ahab

Posted on Aug 31 Originally published at indieseek.co

DeepSeek Harness 0.1.2 Alpha.2 Reconnect Checklist

DeepSeek Harness 0.1.2 alpha.2 connection recovery: make reconnects visible before trusting resume

Quick answer

DeepSeek Harness v0.1.2-alpha.2, published on August 30, 2026, makes Web-client connection failures visible, retries automatically, and adds an immediate reconnect action. That is useful, but it is not proof that every interrupted agent event was replayed. Treat recovery as two separate questions: did the transport reconnect, and did the session projection catch up without gaps or duplicates?

The tagged source uses a 2-second WebSocket heartbeat, a 3-second generation-readiness timeout, and six jittered retry waits before settling on disconnected. A manual reconnect interrupts the active generation or pending delay and starts a fresh attempt immediately. These are implementation facts at tag commit 0a53fb55; the project still labels itself a Developer Preview with compatibility-breaking changes.

Who this is for

This runbook is for independent developers running long DeepSeek Harness sessions in the Web UI, especially when subagents, schedules, or background jobs can continue while the browser-to-Host connection changes. It is also useful for teams wrapping the Harness behind SSH, a reverse proxy, or a private gateway where a green process check does not prove the browser stream is healthy.

If you need crash, compaction, and durable-history recovery, use the session persistence and replay guide. This article covers the narrower transport and projection handoff: browser network state, WebSocket replacement, readiness, cursor continuity, and operator evidence.

What changed and what did not

The official alpha.2 release adds visible connection failure state, automatic retry, and an immediate reconnect action. The same release also improves long-history and dense live-message processing, shows per-answer token usage and elapsed time, and exposes effective endpoints when web_search fails.

The tagged connection controller establishes the recovery contract:

Condition	Controller behavior	Evidence to require
Healthy initial connection	No recovery indicator after the first ready frame	One connected generation and no retry warnings
Browser reports offline	Abort active work, publish `disconnected`, suspend automatic retries	No new socket attempts while offline
Browser returns online	Publish `connecting`, reset the attempt number, restart at the base tier	Fresh socket plus a new ready frame
Transport or readiness fails	Replace the generation using jittered exponential backoff	One `retry #N` warning per physical attempt
User presses reconnect	Interrupt the generation or delay and attempt immediately	No parallel retry loop; attempt sequence resets
Final capped attempt fails	Stop automatic attempts and stay `disconnected`	Stable action for manual recovery, not endless traffic

navigator.onLine only decides whether retries should run. The source explicitly treats a fresh $events ready frame as Host-connectivity proof. Likewise, a visible Connected state proves a generation opened; it does not by itself prove every one-way notification was replayed.

Know the retry timeline

The default backoff cap begins at 500 ms, doubles through 1, 2, 4, and 8 seconds, then reaches the 10-second cap. Each actual delay is randomly chosen from 50% to 100% of its cap. The tagged test expects six retries after the initial failed connection:

Retry	Delay range
1	250–500 ms
2	500–1,000 ms
3	1–2 seconds
4	2–4 seconds
5	4–8 seconds
6	5–10 seconds

The waits therefore total roughly 12.75–25.5 seconds, excluding failed readiness and network time. Do not write an alert that assumes an exact reconnect second. Alert on state transitions, attempt count, and the terminal disconnected state.

A seven-stage rollout

1. Pin the alpha and preserve rollback

Record dsh-v0.1.2-alpha.2, commit 0a53fb55bea101816fa226bb964ae2bed71c343b, Node.js version, launch command, Host URL, and reverse-proxy path. Keep the previous build available. The official README says the project is a Developer Preview, not stable GA.

2. Capture the healthy baseline

Open one disposable session and record the initial generation ID, latest durable event sequence or cursor, visible answer count, active jobs, and active schedules. Confirm the recovery indicator is absent during uninterrupted operation. A permanently visible “connected” badge would make a later transition less useful.

3. Test browser-offline suspension

Use browser network emulation or disconnect the client network while leaving the Host alive. Expect disconnected quickly and zero new connection attempts during a 60-second offline window. Duplicate offline events must not create more loops.

4. Exercise bounded automatic retry

Bring the browser online while deliberately rejecting the WebSocket upgrade. Capture each retry warning and socket attempt. Expect six retries after the initial attempt, then a stable disconnected state. If attempts continue indefinitely, stop the rollout: the deployed client is not following the tagged controller.

5. Exercise one manual reconnect

While the client is waiting in backoff, restore the Host and press Reconnect now once. Expect the delay to be interrupted, the attempt sequence to reset, exactly one socket replacement, and a ready frame. Do not repeatedly click; that tests operator impatience rather than recovery correctness.

6. Reconcile projection and durable work

After reconnect, compare the pre-failure cursor with the fresh baseline or replay cursor. Verify that completed messages appear once, active background work remains owned by the same session, and schedules or jobs did not duplicate. A reconnect may disrupt shared logical streams; non-replayed one-way notifications need separate reconciliation. Use the delegation ownership guide when subagents are involved.

7. Promote only with evidence

Run the same canaries through the real proxy or SSH path. Keep retry count, time to ready, terminal disconnect count, cursor gap, duplicate event count, and post-reconnect job ownership in your acceptance record. Roll back if transport recovery succeeds but projection evidence does not.

Copyable acceptance record

version: dsh-v0.1.2-alpha.2
commit: 0a53fb55bea101816fa226bb964ae2bed71c343b
surface: web / proxy / ssh
initial_generation: 
cursor_before_failure: 
offline_attempts_60s: 0
automatic_retry_warnings: 6
terminal_state: disconnected
manual_reconnect_socket_replacements: 1
ready_frame_received: yes|no
cursor_after_recovery: 
missing_events: 0
duplicate_events: 0
jobs_or_schedules_duplicated: 0
rollback_required: yes|no

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Calling an alpha release stable because the reconnect UI looks polished.
Treating navigator.onLine=true, an HTTP health check, or a green Host process as a ready WebSocket generation.
Assuming Connected means every live event was replayed exactly once.
Alerting on a fixed 13- or 26-second deadline even though backoff is jittered and readiness has its own timeout.
Clicking reconnect repeatedly and then diagnosing duplicate physical attempts as an automatic-retry bug.
Logging transcript content or credentials when generation ID, cursor, state, and counts are enough.

FAQ

Does alpha.2 retry forever?

No. The tagged controller stops automatic recovery after the failed retry in the capped 10-second tier and publishes disconnected. A manual reconnect can start another sequence.

Does manual reconnect preserve the same session?

It replaces the connection generation, not the session identity. Session continuity still depends on fresh baseline or cursor replay and must be verified independently.

Is the two-second heartbeat configurable?

Yes. The tagged Gateway config exposes websocketHeartbeatIntervalMs, with 2,000 ms as the validated default. Changing it alters failure-detection traffic and timing, so record the deployed value.

Should I upgrade production immediately?

Use a canary first. The release is an alpha inside a Developer Preview. Promote only after the transport timeline and session-projection checks pass through your actual deployment path.

Sources

Originally published at IndieSeek.

DEV Community