Python SDK: resuming a persisted session in a new process fails with id collision; session/load and session/resume are not exposed

[lzc8568]

Summary

deepseek-harness-sdk 0.1.0rc6 cannot resume a persisted session from a fresh runtime process. The first run() on a session works, but any later run() with the same session_id in a new process (e.g., after the host process restarts, or when a server runs multiple workers and the next turn lands on a different worker) ends immediately with an empty response:

turn/end reason.kind = "error"
error.message = 'session "<id>" already has a persisted log on disk that does not match this live session (id collision)'

Expected behavior

A persisted session should be resumable from a new process. The runtime already implements session/load / session/resume (ACP methods), so a subsequent prompt should continue the conversation with the restored context instead of failing.

Actual behavior

• First turn on a fresh session: works; assistant/chunk deltas and a final assistant/message are produced.
• Second turn with the same session_id from a new runtime process: immediately turn/end with reason.kind == "error" and the "id collision" message above. No assistant/chunk events; final_response is empty; finish_reason == "error".
• Two sequential run() calls with the same session_id in the same runtime process: both succeed (the in-memory session object is reused).
• Calling session/load (or session/resume) directly via harness.client.request(...) fails with JsonRpcError: unknown DeepSeek Harness SDK runtime method: session/load — the SDK JSON-RPC server only accepts initialize, session/prompt, and shutdown.

Reproduction

Environment: deepseek-harness-sdk==0.1.0rc6 + bundled runtime (deepseek-harness-runtime-bin==0.1.0rc6), model deepseek-v4-flash via the official provider, Python 3.12.

from deepseek_harness import DeepSeekHarness

cfg = dict(provider="deepseek-official", model="deepseek-v4-flash",
           cwd="/tmp", session_root="/tmp/dsh-sess")

# 进程 A：第一轮（新会话）
h1 = DeepSeekHarness(**cfg)
r1 = h1.run("只回复：一", session_id="dsh-resume-test")
print(r1.finish_reason, r1.final_response)  # completed, "一"
h1.close()

# 进程 B：新运行时恢复同一会话 → id collision，空回复
h2 = DeepSeekHarness(**cfg)
r2 = h2.run("只回复：二", session_id="dsh-resume-test")
print(r2.finish_reason, repr(r2.final_response))  # error, ''

Impact

• Multi-turn conversations cannot survive a host process restart, which is common in server deployments (deploys, restarts, or multiple uvicorn workers behind a load balancer).
• Current workaround: start a fresh session for every turn and feed the previous messages back through the prompt. This loses tool/Bash state between turns and duplicates context.

Suggested fix

• Expose session/load (or session/resume) through the SDK JSON-RPC server — the runtime already implements these ACP methods; or
• Make session/prompt adopt an existing persisted log when the requested session is not already live (treat "load/resume it instead of creating" as the default for existing sessions).

Environment

• deepseek-harness-sdk 0.1.0rc6 (latest on PyPI)
• deepseek-harness-runtime-bin 0.1.0rc6
• Python 3.12; reproduced on macOS arm64 and Linux x64 bundled runtimes

[jiaoqsh]

+1, with an embedder's data point and the workaround we ended up shipping.

We drive the SDK runtime as one of several agent runtimes inside a host
application. The host's sessions are long-lived and survive backend restarts and
runtime-cache evictions, so "a later run() with the same session_id lands on
a fresh runtime process" is our steady state, not an edge case — every restart
hits the id collision described here.

Two additions to the report:

1. The interrupt story compounds it. The SDK wire has no cancel method, so a
   host that must stop a turn kills the subprocess — after which continuing
   that session requires exactly the resume this discussion asks for. Today the
   two missing methods multiply each other.
2. Our workaround, for anyone stuck on this: we keep persistence off in the
   composition, record a {role, text} transcript sidecar per session on the
   host side, and on each new process we mint a fresh native session id and
   prepend the sidecar as a <conversation-history> block to the first prompt.
   It restores conversational continuity but is text-level fidelity only — tool
   calls/results and reasoning are not replayed, and the model treats the
   history as narration rather than native context.

Server-side load/resume of the persisted log (as proposed here) would let us
delete that machinery entirely — the JSONL store's own error message already
points at the right design ("load/resume it instead").

[alex-makang]

+1 This is critical for me as well.