ai, ai-persistence: a nested subagent that waits runs again from the start under withPersistence
メンテナーはふだん 1 日以内に返信
@tombeckenham がすでに取り組んでいます。
2026年10月22日 から。
評価
この issue はまだ評価されていません。
説明
TanStack AI version
@tanstack/ai and @tanstack/ai-persistence on main, after #1806.
Framework/Library version
Node 24.8.0. Server only.
Describe the bug and the steps to reproduce it
Under withPersistence, a nested subagent that waits on an interrupt runs again from the start after the resume.
Since #1806, a waiting child resumes from loadChild(...).pending, the stored messages, not from the client card. The store keeps a nested child in its own thread (subagent:<id>). So the pending of the outer child has its tool call, but no card for the nested child that waits. Core then finds no suspended child inside the outer child (readSubagentTurn in agents/turn.ts), and runs the nested child again.
Steps:
- A lead agent calls a
researcheragent tool. The researcher calls awriteragent tool. The writer callswrite_file, which needs approval. - Run the turn. It stops on the writer's approval.
- Resolve the approval.
- The writer runs again from its prompt.
write_filedoes not run. A real model asks for the approval again.
packages/ai-harness/tests/subagent-waits.test.ts "waits for an agent that an agent tool calls, and both go on" on feat/harness-core fails on this.
A quick fix copies the nested cards from the client onto the stored message. That trusts the client's messages for the nested child, which #1806 closed one level up: a forged card can change the args of the nested tool call before the approval runs it. Do not ship that.
Fix design: the card is a pointer, the store gives the contents
LoadChildtakes an optional parent (packages/ai/src/activities/chat/middleware/load-child.ts):(subagentRunId, options?: { parentSubagentRunId?: string }). The result also getsinterruptIds?andparentToolCallId?, read from the stored info, so the card is not the source.withPersistencepasses the parent on (packages/ai-persistence/src/middleware.ts,provideLoadChild): with a parent, the caller is{ threadId: ctx.threadId, subagentRunId: parentSubagentRunId }. The existing check inloadChild(marker.parentThreadId !== ownerThread(caller)) proves that the nested child belongs to that parent. Core asks for a nested child only after it loaded the parent, so the chain is checked from the top.loadChildreturnsinterruptIdsandparentToolCallId(packages/ai-persistence/src/subagent-runs.ts), fromstoredSubagentInfo.- Core rebuilds nested cards from the store (
packages/ai/src/activities/chat/agents/spawn.ts,runChild): for each card subagent part whoseparentToolCallIdis a tool call in the storedpending, callload(id, { parentSubagentRunId }). Nopendingmeans throw "not waiting", as the top level does. Build the part from the store: messages frompending,interruptIds,parentToolCallId,status: 'suspended'. Take only the id from the card. Repeat for deeper nesting.
The LoadChild change is additive. A loader that ignores the parent fails closed for nested children.
Tests:
- The nested resume:
write_fileruns once after the approval, and the writer model is called twice. - A nested card with changed
write_fileargs does not change what runs (like the #1806 forged-card test, one level down). - A nested card that names a child of another parent throws "not waiting".
Docs: the pending line in docs/chat/subagents.md. Add a changeset.
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
packages/ai-harness/tests/subagent-waits.test.ts on feat/harness-core, test "waits for an agent that an agent tool calls, and both go on". The same three-level setup works with plain chat() and withPersistence on main.
Do you intend to try to help solve this bug with your own PR?
Yes, I am already working on a fix
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.2k
- フォーク
- 372
- 平均マージ
- 1日 12時間
- マージ済み PR（30日）
- 266
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/ai のほかの issue
-
Durable resume through withPersistence never fills ctx.inputResponse for mcp_input interrupts対応中かも @tombeckenham が 2 日前に担当しました。 オープンwaiting-on: maintainer
メンテナーはふだん 1 日以内に返信
-
ai-ollama: streamed chat() reports finishReason "stop" when done_reason is "length"対応中かも @AlemTuzlak が 3 日前に担当しました。 オープンwaiting-on: maintainer
メンテナーはふだん 1 日以内に返信
-
Discriminate status-dependent record and option types (RunRecord, SessionIndexEntry, InputState, durable-only options)対応中かも @jherr が 9 日前に担当しました。 オープンenhancement waiting-on: maintainer
メンテナーはふだん 1 日以内に返信
-
move to modelschemas対応中かも @jherr が 10 日前に担当しました。 オープンhas-pr waiting-on: maintainer
メンテナーはふだん 1 日以内に返信
-
chat(): sign the state of a suspended run so a resume without persistence cannot change it対応中かも @AlemTuzlak が 12 日前に担当しました。 オープンwaiting-on: maintainer
TanStack/ai#1740 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 70/100
microsoft/playwright#43640 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
grasshopper-protocol/grsshppr#172 ·
メンテナーはふだん 1 日以内に返信
-
bug help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Tencent/teamai-cli#1397 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
DouyinFE/semi-design#3641 ·
メンテナーはふだん 3 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信