[Bug] Manual /compact aborts after 5–15s with "DeepSeek request aborted by caller" — 22/23 attempts fail (rc.7 & rc.8)

[wzl-plasmid]

Summary

Running /compact manually on an idle agent almost always fails. The compaction starts, then ~5–15 seconds later the command is aborted with This operation was aborted and the compaction ends with DeepSeek request aborted by caller. 23 attempts across rc.7 and rc.8, 22 failures, 1 success. This is not a network, proxy, or user-cancellation issue — it appears to be a framework-level abort during the summarization LLM stream.

Environment

• Product: dsh web (Cordis-based), local GUI at http://127.0.0.1:3080
• Version: @deepseek-ai/dsh@0.1.0-rc.7 (initial) and 0.1.0-rc.8 — reproduced on both
• Agent preset: cordis
• Model route: deepseek-official / deepseek-v4-flash, reasoningEffort high
• OS: Linux; agent idle; no subagents running; single browser tab

Steps to reproduce

1. Let the agent finish a turn and become fully idle (turn/end logged).
2. Run /compact (no arguments) — either via the UI command or the command channel.
3. Observe: compaction/start is appended, then after ~5–15 s the command aborts.

Expected behavior

/compact runs the summarization LLM stream to completion and replaces the selected history with a checkpoint summary (the one successful run took 31 s end-to-end and worked).

Actual behavior

From the session log (event stream, seq order shown):

command/run        → /compact (source: user)
compaction/start   → compactionId=…, sourceCommandId=…, turn: null
   …5–15 s later…
command/done       → kind: error, text: "This operation was aborted"
compaction/end     → error: "DeepSeek request aborted by caller"

Attempt log (all manual, user-triggered):

When	Version	Command	Result
08-19 15:12–15:16	rc.7	cmd-f595a38d-1..5	4 aborted, 1 success (31 s)
08-19 18:27–18:28	rc.7	cmd-9392d761-1..5	5 aborted
08-20 12:53–13:17	rc.7	cmd-e516b094-1..10	10 aborted
08-20 13:59	rc.8	cmd-a406feab-1..3	3 aborted — bug still present

Total: 23 attempts across rc.7 and rc.8, 22 aborted, 1 success.

rc.8 verification (2026-08-20): after upgrading to 0.1.0-rc.8 (npm i -g @deepseek-ai/dsh@next), the first manual /compact in a fresh rc.8 process (cmd-a406feab-1) still failed with the identical pattern: compaction/start → ~8 s → command/done "This operation was aborted" → compaction/end "DeepSeek request aborted by caller". Two more attempts (cmd-a406feab-2/3) failed the same way. The three code paths implicated below (compactNow signal fusion, DeepSeek adapter ABORTED throw, api-gateway token lifecycle) are byte-identical between rc.7 and rc.8.

Root-cause analysis (from code + runtime checks)

The summarization stream is created in dsh-compaction-basic compactNow():

return agent.runMaintenance(async (agentSignal) => {
  const operationSignal = AbortSignal.any([agentSignal, signal]);
  ...
  return await compactSurfaceRegion(..., operationSignal);
});

and the DeepSeek adapter (dsh-llm-deepseek) throws exactly this error when the caller signal is aborted:

// dsh-llm-deepseek lib/index.js (stream() catch block)
if (options.signal?.aborted)
  throw new LlmError("DeepSeek request aborted by caller", "ABORTED", { cause: error });

So the failure is an ABORTED (caller signal aborted), not:

• a stream idle timeout (TIMEOUT, reason LLM_STREAM_IDLE_TIMEOUT),
• an SSE EOF without [DONE] (STREAM_CLOSED),
• a user cancel (abortError(signal) would carry a reason; here signal.reason is empty → "This operation was aborted"),
• a "busy" rejection (session is idle; compaction/start proves the lock was acquired).

The command's cancellation signal originates in dsh-api-gateway invoke():

const callerSignal = hasCallerSignal ? values[expected] : void 0;
const signal = callerSignal === void 0 ? token.abort.signal
            : AbortSignal.any([token.abort.signal, callerSignal]);

For /compact no caller signal is passed, so the signal is the Remote install token's abort signal (token.abort.signal). That token is aborted only when the Remote service is installed/disposed (install() / its returned disposer). With zero session activity, no cancel events, no inbox changes, and a stable WebSocket events stream (verified 30 s stable), the only plausible abort source is that install token being disposed/remounted mid-compaction — a lifecycle race in the RPC layer, not a user/network condition.

What I verified (to rule out environment causes)

• DeepSeek API reachable directly and via proxy (HTTP 401 as expected, ~0.17 s).
• The dsh host process has no proxy env vars; its LLM fetch goes direct (Node native fetch, no setGlobalDispatcher/proxy agent in dsh-llm-deepseek).
• The command channel is healthy: other commands (/goal) return in 0.2 s via the same /api/commands/execute path.
• WebSocket /api/events.mux stayed open 30 s with no drops.
• Session log shows no cancel events, no inbox activity, no subagent activity during the failures.
• One success took 31 s — the LLM summarization stream itself can complete.

Suggested investigation

• Check the lifecycle of the api-gateway Remote install token (token.abort.signal) for long-running commands: is anything disposing/re-installing the commands service (or its containing scope) while a command is in flight?
• Consider whether the compaction summarization stream should be decoupled from the command's cancellation token (e.g. run under agentSignal only, or scope the token to the call rather than the install).

Impact

Manual context compaction is effectively unusable (95% failure rate); users must retry many times or work around it. Automatic pressure/overflow compaction may be affected too.

[zoahdev]

这类"启动后固定 5-15 秒被 caller 中止"的模式，和我们核验过的 compaction 专用链路缺陷 #1944 高度吻合：summarizeWithLlm 只继承 provider/model，强加 maxTokens: 8192，不继承 routed header config——即 compaction 请求与正常回合参数不一致，容易被 provider 侧按固定超时/流空闲判定中止（rc.7/rc.8 都中，与你说"不是网络/代理/用户取消"一致）。补丁已就绪：fix/compaction-inherit-header-config（基于 main 99f6f02，124/124 测试全绿），建议先套上验证是否消除；另外建议你抓一次中止时的 dsh 日志，确认 summarizeWithLlm 发出的请求头/超时参数与正常回合的差异，若固定时长可复现基本就是这条路。

[denial123789]

I turned this report into a source-backed cancellation-chain runbook and kept the lifecycle conclusion deliberately narrower than the hypothesis. The durable event sequence plus the DeepSeek adapter establishes that the summarization options signal was aborted, but the Remote install token remains a candidate owner until its exact generation is observed disposing during the same command.

The runbook adds first-abort reason instrumentation, command/compaction identity joins, a one-attempt Web-versus-non-Web A/B matrix, and a safe continuity path that avoids repeated potentially billable summary attempts:

https://sandbaseai.github.io/deepseek-harness-handbook/manual-compaction-aborted.html

Canonical incident bundle and regression gates:
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/manual-compaction-caller-abort.md

A repair should make the accepted call lifetime stable without removing authentic user or Host cancellation.

[wzl-plasmid]

Thanks to @zoahdev and @denial123789 for the replies — both shaped this investigation.

• @zoahdev: The compaction-path hypothesis (summarizeWithLlm forcing maxTokens: 8192 and not inheriting the routed header config) made us check the summarization request parameters against a normal turn. That check came back clean, and the Chrome-versus-Firefox comparison then ruled the request-parameter axis out entirely, which pushed the investigation onto the transport layer.
• @denial123789: The runbook's methodology — instrument the first abort reason and do not treat the install token as the owner until its disposal is actually observed — is what we ended up doing, one layer down. Socket-level instrumentation of the abort chain captured the actual disposal trigger, and the Web/non-Web comparison the runbook suggested is structurally the same experiment that eventually isolated the browser.

Root cause

The abort is not a compaction-parameter problem, not an api-gateway token lifecycle race, not a proxy, and not a plugin. It is Firefox reaping idle HTTP keep-alive connections.

/compact is a long-lived streaming request (the one success took 31 s). Firefox closes a page's idle keep-alive connections in batches every 30–100 s (irregularly), each close being a client FIN. When a batch happens to include the in-flight compact stream, the socket is destroyed, the AbortSignal fires, and the DeepSeek adapter throws LlmError("DeepSeek request aborted by caller", "ABORTED"). The failure is browser-side and entirely independent of the request contents.

The abort path, confirmed by instrumentation:

compactNow fuses AbortSignal.any
  -> DeepSeek adapter observes options.signal?.aborted
  -> throws LlmError("DeepSeek request aborted by caller", "ABORTED")
  -> the caller signal is request.signal from rpcFetchHandler
  -> the bridge aborts on res "close" when !res.writableEnded
  -> Firefox reaps the connection: socketOnEnd (node:_http_server) -> destroy

Evidence

1. Same dsh instance, same session: /compact succeeds in Chrome and always fails in Firefox. This is the decisive experiment — it rules out the server, the request parameters, the token lifecycle, and the API in one move.
2. Socket instrumentation on the webserver shows periodic bursts of SOCKET END immediately followed by SOCKET DESTROY, at irregular 30–100 s intervals. Connections are reaped in batches.
3. Every reaping stack is socketOnEnd (node:_http_server:858), i.e. the client sent the FIN and the server responded passively. A server-side timeout would emit SOCKET TIMEOUT instead; that event was observed to arrive late with destroyed=true, so the server is not the initiator.
4. Of 111 destroyed connections, 108 had writableEnded=true (idle keep-alive connections) and 3 had writableEnded=false (SSE long-lived connections such as /plugins/events, which is normal). The compact stream is destroyed as collateral of the idle-pool reaping.
5. Disabling the whole @linxin666/dsh-web-ui-all bundle, HMR, and both pets (live2d-pet, web-ui-pet) one at a time did not stop the bursts.
6. Firefox settings do not match the cadence: network.http.keep-alive.timeout is the 115 s default, browser.tabs.unloadOnLowMemory is false, and the installed extensions (Plasma Integration, Tampermonkey, Zotero Connector) are not connection managers.

The single success (14:59:45 → 15:00:25) completed between two reaping bursts; it was luck, not a configuration difference.

Suggested fix

The client cannot be made to stop reaping connections, so dsh should treat a transient connection loss as recoverable:

1. In dsh-compaction-basic, distinguish an explicit user cancel from an externally destroyed socket when an ABORTED error arrives, and retry or silently resume in the latter case instead of surfacing DeepSeek request aborted by caller.
2. In dsh-llm-deepseek, distinguish the abort source at the options.signal?.aborted check. An abort caused by socket destruction (res close with !res.writableEnded) should retry rather than throw ABORTED.
3. Optionally, make compaction chunked and idempotent so an interrupted run can resume from the last committed chunk, removing the long streaming window entirely.

Workarounds until the fix

• Run /compact in Chrome (verified stable).
• In Firefox, keep compact runs short to reduce the chance of landing inside a reaping window. Keeping the tab or window in the foreground does not help; the reaping occurs in the foreground too.

Environment

• dsh 0.1.0-rc.8 (global bin), also reproduced on 0.1.0-rc.7
• Firefox (fails) / Chrome (succeeds)
• Firefox: network.http.keep-alive.timeout 115 s (default), browser.tabs.unloadOnLowMemory false
• Extensions: Plasma Integration, Tampermonkey, Zotero Connector
• No proxy involvement; Clash was not running during the failing runs

Diagnostic method

Socket lifecycle events (end, close, timeout, destroy) on req.socket in dsh-host-webserver were logged with stacks and writableEnded. The discriminator: SOCKET END and SOCKET DESTROY coincide and the stack is socketOnEnd, meaning a client FIN; SOCKET TIMEOUT arrives late with destroyed=true, ruling out server timeouts. All instrumentation was removed after diagnosis; the touched packages are byte-identical to the npm originals (md5-verified).

[zoahdev]

收到，也感谢把排查闭环做得这么扎实。你给出的 Chrome/Firefox A/B、socket END/DESTROY 栈和 writableEnded 统计已经把故障定位到 Firefox 对长连接的回收；这组直接证据推翻了我之前关于 compaction 请求参数/路由头的假设，应以你现在的 transport-layer 根因为准。#1944 的 header 继承问题仍是独立缺陷，但不应再被用来解释本讨论中的固定中止。建议后续修复也保持你提出的边界：区分显式用户取消与连接被动断开，并确保重试/续跑是幂等且不会造成重复计费。