Reconnecting to a durable sandbox run during a long tool call delivers the rest of the run twice

未关闭
  • 哪里不对？
#2,035 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@tombeckenham 已经在做这个了。

开始于 2026年11月4日。

评估

这个 Issue 还没有评估数据。

描述

waiting-on: maintainer
TanStack AI version

@tanstack/ai 1.1.0, @tanstack/ai-sandbox 1.1.0, @tanstack/ai-client 1.1.0, @tanstack/ai-claude-code 1.0.1, @tanstack/ai-sandbox-local-process 1.0.0

Framework/Library version

Node.js 26.13.0 and 24.22.2. No UI framework: the server and the clients run in one Node script.

Describe the bug and the steps to reproduce it

When a client reconnects to a durable sandbox run while the agent is in a tool call that lasts more than 5 seconds, the rest of the run is written to the run log twice. The reconnected client receives every later event twice, and the text deltas interleave:

Running the long command.The The long long command command finished. finished. Each Each word word of of this this reply reply is is one one delta.delta.

Expected: every event arrives once, as it does when nobody reconnects.

Steps. The repro does all of them with pnpm install && pnpm start. It needs no API key.

  1. A POST route starts a durable run as docs/sandbox/takeover.md shows: chat() with claudeCodeText, withLocks(locks), and withSandbox(sandbox, { runs, instances, durability: { adapter } }), returned with toServerSentEventsResponse(stream, { durability: { adapter } }). The sandbox is localProcessSandbox(). The log is memoryStream. The stores are InMemoryRunStore, InMemorySandboxInstanceStore, and InMemoryLockStore.
  2. A GET route returns resumeServerSentEventsResponse with sandboxRunDriver({ request, runs, locks, durability, drive }). drive calls chat() again with attach: true.
  3. The agent makes one Bash call that takes 15 seconds, then streams a 12-word answer. To run without a model, claudeExecutable points at fake-claude.mjs, which prints Claude Code stream-json.
  4. At 3 seconds, a ChatClient calls stop() with no cancelUrl. The connection closes and the run is not cancelled.
  5. At 3.5 seconds, a second client finds the active run and calls fetchServerSentEvents(url).joinRun(runId).

Output:

[   15 ms] locks.withLock("sandbox:80f0ccca17217a27")
[ 3004 ms] tab 1: disconnects (no cancel)
[ 3511 ms] tab 2: joinRun("run-1793812048416-e9jvxh")
[ 3513 ms] locks.withLock("run-driver:run-1793812048416-e9jvxh")
[ 8514 ms] takeover: drive() starts
[ 8515 ms] locks.withLock("sandbox:80f0ccca17217a27")
...
Tab 2 received:
  TOOL_CALL_RESULT     2   (expected 1)
  TEXT_MESSAGE_CONTENT 25  (expected 13: 1 before the tool call, 12 after)
  RUN_FINISHED         1   (expected 1)

The run log holds:
  TOOL_CALL_RESULT     2   (expected 1)
  TEXT_MESSAGE_CONTENT 25  (expected 13: 1 before the tool call, 12 after)
  RUN_FINISHED         2   (expected 1)

Appends to the run log, by producer:
  POST producer: 37 chunks, TOOL_CALL_RESULT 1, TEXT_MESSAGE_CONTENT 13, RUN_FINISHED 1
  takeover driver: 18 chunks, TOOL_CALL_RESULT 1, TEXT_MESSAGE_CONTENT 12, RUN_FINISHED 1

RESULT: DUPLICATED

The events were duplicated in 7 of 7 runs, on Node 26 and Node 24. With a 4-second tool call (TOOL_MS=4000 DISCONNECT_AT_MS=1000 pnpm start), every event arrived once in 3 of 3 runs. We first saw this with the real Claude Code CLI in a Vercel sandbox, a Redis log, and a 45-second Bash command.

Suspected cause (not confirmed). After the disconnect, toServerSentEventsResponse keeps draining the POST run into the log, as it should for a detached run. That producer never takes the run-driver:<runId> lock or a driverEpoch. The lock lines above show that only the takeover takes it. So fenceDurability cannot stop the POST producer, and the only remaining guard is awaitLogQuiescence (DEFAULT_FENCE_QUIET_MS = 5_000). A tool call that keeps the log quiet for more than 5 seconds passes that guard, and then both producers translate the same journal and append the same events. For this reason, I expect a distributed lock store to give the same result. The e2e test "a real disconnect, then an attach, continues the stream" simulates the disconnect by aborting the POST run's controller. That abort stops the POST producer, so the test may not cover this path.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

https://github.com/adelrodriguez/tanstack-ai-repros/tree/main/takeover-duplicates-stream

Screenshots or Videos (Optional)

No response

Do you intend to try to help solve this bug with your own PR?

Maybe, I'll investigate and start debugging

Terms & Code of Conduct
  • I agree to follow this project's Code of Conduct
  • I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
主要语言
TypeScript
星标
3.3k
派生
378
平均合并
1 天 2 小时
30 天内合并 PR
254

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

TanStack/ai 的其他 Issue

查看 TanStack/ai 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。