Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Durable resume through withPersistence never fills ctx.inputResponse for mcp_input interrupts

Đang mở
  • Có gì không ổn?
#1,885 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@tombeckenham đang làm issue này rồi.

Từ ngày 23/10/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

waiting-on: maintainer
TanStack AI version

@tanstack/ai 1.0.0 (also seen in 0.69.0)

Framework/Library version

Node.js 24, server-side chat() with withPersistence; no framework involved

Describe the bug and the steps to reproduce it

A server tool that pauses on an input request gets its answer on ctx.inputResponse when the next run is resumed from the messages the client sends. When the run is resumed through withPersistence (the durable path, messages: [] and the stores rebuild the thread), the answer never reaches ctx.inputResponse. The tool is called again with inputResponse undefined, so it asks the same question again.

Steps

  1. A server tool throws an input request on its first call and reads the answer on the second:
import { toolDefinition } from '@tanstack/ai'
import { z } from 'zod'

const askCity = toolDefinition({
  name: 'ask_city',
  description: 'Ask the user which city to use',
  inputSchema: z.object({}),
}).server(async (_args, ctx) => {
  if (ctx.inputResponse?.status === 'resolved') {
    return { city: (ctx.inputResponse.payload as { value: string }).value }
  }
  throw Object.assign(new Error('Input required'), {
    name: 'MCPInputRequiredError',
    kind: 'form',
    request: {
      message: 'Which city?',
      requestedSchema: {
        type: 'object',
        properties: { value: { type: 'string' } },
        required: ['value'],
      },
    },
  })
})

  1. Run it under withPersistence. The first run ends with RUN_FINISHED and an interrupt outcome whose item id is mcp_input_<toolCallId>, and the stores park it.

  2. Resume with the answer, the way a durable continuation does:

chat({
  adapter,
  messages: [], // the stores own the history
  threadId,
  runId: nextRunId,
  parentRunId: interruptedRunId,
  resume: [
    {
      interruptId: `mcp_input_${toolCallId}`,
      status: 'resolved',
      payload: { value: 'Paris' },
    },
  ],
  tools: [askCity],
  middleware: [withPersistence({ /* stores */ })],
})

Expected: askCity is called again with ctx.inputResponse set to { status: 'resolved', payload: { value: 'Paris' } }, as it is on the ephemeral resume.

Actual: ctx.inputResponse is undefined, so the tool throws the same input request again and the run parks a second time.

Where it happens

I found this by reading the source, not by bisecting. In src/activities/chat/index.ts at 1.0.0:

  • applyEphemeralInterruptResume (around line 5253) collects the mcp_input_* ids of the pending server tool calls and copies each resolution into resumeInputResponses (around line 5427). That map is what executeToolCalls reads to set ctx.inputResponse.
  • applyResumeToolState (around line 5614), which applies the resumeToolState that middleware such as withPersistence hands back from onConfig, copies genericInterrupts into resumeGenericInterrupts but never into resumeInputResponses.

So the mcp_input_* resolution survives the durable resume as a generic interrupt resolution, but the tool it belongs to never sees it. A possible fix is for the durable path to map mcp_input_<toolCallId> resolutions to resumeInputResponses the same way the ephemeral path does.

Workaround: read the resolution out of the stores and pass it to the tool through chat({ context }), keyed by tool call id.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

No sandbox; the snippets above are the minimal shape, and the source locations show the gap.

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

No, because I don't have time to dive into it

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.
Ngôn ngữ chính
TypeScript
Star
3.2k
Fork
372
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
266

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/ai

Tất cả issue của TanStack/ai

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.