Skip to content

ci: Version Packages#968

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

ci: Version Packages#968
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@tanstack/ai@0.43.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

  • #970 3301398 - Make interrupt ownership explicit rather than assumed.

    An AG-UI Interrupt is a shared envelope — a workflow engine's durable
    approval or another agent framework's pause can arrive on the same stream. What
    makes a pause resumable through chat() is the binding this package attaches
    under tanstack:interruptBinding.

    • Interrupts that carry no binding this client understands now surface as
      kind: 'unbound' with canResolve: false, instead of being given a
      synthesized binding and rendered as resolvable generic interrupts. Resolving
      those produced an answer submitted against a run with nothing pending, which
      failed as unknown-interrupt only after the user had filled in the form.
      Unbound items never block submission of the interrupts that are yours.
    • The binding carries a wire version (INTERRUPT_BINDING_VERSION). Readers
      reject a version they don't recognise rather than duck-typing its fields. A
      binding written before the field existed is still read.
    • INTERRUPT_BINDING_METADATA_KEY, withInterruptBinding() and
      readInterruptBinding() are exported, so anything producing an interrupt this
      package must later resume attaches the binding through a supported API
      instead of copying the metadata key.
    • Interrupt classification is driven by the binding alone. Interrupt.reason is
      free-form AG-UI text another producer can also use, so it is now a display
      hint only and never decides ownership.
    • The interrupt protocol surface is enumerated instead of export *. The
      unimplemented durable-recovery contract (InterruptRecoveryStateV1,
      InterruptRecoveryQuery, the never-called loadInterruptState adapter hook,
      and the persistence-required / atomic-commit-unsupported /
      recovery-unavailable error codes) is removed rather than published.

  • #970 3301398 - Interrupts: the application owns wire-schema validation, and the hashing
    dependency is gone.

    The library no longer transforms a generic interrupt's wire JSON Schema into a
    validator or validates the resolved value against it, on either the client or
    the server. Whatever you pass to resolveInterrupt (client) or send in the
    resume batch (server) flows through as-is. Validate it yourself if you need to
    trust it, e.g. with z.fromJSONSchema(interrupt.responseSchema).safeParse(value)
    on the client and your own check on the server. Validation of a tool's
    code-authored Standard Schema (approvalSchema / inputSchema) is unchanged.

    This drops the ajv and ajv-formats dependencies. Interrupt binding hashes and
    resolution fingerprints now use a small bundled SHA-256 instead of
    @noble/hashes, so that dependency is gone too. The wire hash shape
    (sha256:<hex>) is unchanged.

  • #955 7c7aa09 - Resumable streams: reconnect to an in-flight SSE or NDJSON response without
    re-running the provider.

    toServerSentEventsResponse and toHttpResponse both accept a
    durability: { adapter, batch } option. The adapter (StreamDurability)
    records every chunk to an ordered log before delivery and tags each event with
    an opaque, adapter-owned offset — an SSE id: line, or the id of an NDJSON
    { id, chunk } envelope (NDJSON has no native event-id). A reconnect
    (Last-Event-ID) or an explicit ?offset read replays strictly after that
    offset from the log — the lazy provider stream is never iterated on resume.
    Producers terminalize the log on cancellation and failure (RUN_ERROR append

    • close()) and on completion when the source stream emits its own terminal
      event (chat() always does), so readers are never parked on a dead run.

    Two adapters ship: memoryStream(request) in @tanstack/ai (process-local,
    for development and tests) and the new @tanstack/ai-durable-stream package,
    a Durable Streams protocol adapter for production backends.

    For the GET handler that a reload or a second tab reconnects to,
    resumeServerSentEventsResponse({ adapter }) and resumeHttpResponse({ adapter })
    replay a run straight from the durability log. They need no producer stream and
    return a 400 when the request carries no resume offset.

    On the client, all four HTTP adapters are now resumable — fetchServerSentEvents,
    fetchHttpStream, xhrServerSentEvents, and xhrHttpStream. Each tracks the
    per-event offset, auto-reconnects with Last-Event-ID, de-duplicates the
    replayed prefix, and exposes joinRun(runId) to attach to an in-flight or
    finished run from the start (read-only GET with offset=-1). Untagged streams
    behave exactly as before. A durable run that ends with no terminal event and no
    forward progress now throws DurableStreamIncompleteError instead of hanging.

    Reconnection and durability are bounded so failures surface rather than hang or
    loop:

    • memoryStream evicts completed logs after a grace window (unbounded growth
      is gone); resuming an expired/unknown run throws, and a from-start join to a
      run that never produces fails after MemoryStreamOptions.firstChunkDeadlineMs.
    • all four HTTP adapters accept reconnect: { maxAttempts, delayMs } — a
      throttle plus a ceiling on CONSECUTIVE no-progress reconnects (default 5;
      forward progress resets it) that fails with the new StreamReconnectLimitError
      instead of reconnecting endlessly, without penalizing a healthy long-lived run.
    • durableStream accepts reconnect: { maxReadFailures, delayMs } to bound its
      read-retry loop, and server is now optional when fetch is provided (e.g. a
      Cloudflare service binding).
    • toServerSentEventsResponse accepts debug to record durability terminal /
      close failures server-side, where a replaying joiner cannot observe them.

  • #980 4ce7600 - Add a shared Scope identity type to @tanstack/ai.

    Scope is the single identity/isolation vocabulary for the subsystems that
    persist or recall per-conversation data — @tanstack/ai-persistence and
    @tanstack/ai-memory. Rather than each subsystem inventing its own notion of
    "whose data is this?", both import one type:

    interface Scope {
  threadId: string // required — the single conversation key (same as ctx.threadId)
  userId?: string // durable end-user identity; required in practice for multi-user apps
  tenantId?: string // multi-tenant boundary
  namespace?: string // reserved logical partition; no subsystem keys on it yet
}

    threadId is the one conversation key across the codebase (matching
    ChatMiddlewareContext.threadId, with conversationId already deprecated in
    favor of it) — subsystems must not introduce a second name (sessionId, …) for
    the same concept. Every field is an isolation boundary and must be derived
    server-side from trusted session state, never from client input.

    This is additive: nothing consumes Scope yet. It lands ahead of the
    persistence and memory PRs so both build on one settled, unambiguous identity
    contract instead of diverging.

@tanstack/ai-angular@0.4.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-client@0.23.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

  • #970 3301398 - Make interrupt ownership explicit rather than assumed.

    An AG-UI Interrupt is a shared envelope — a workflow engine's durable
    approval or another agent framework's pause can arrive on the same stream. What
    makes a pause resumable through chat() is the binding this package attaches
    under tanstack:interruptBinding.

    • Interrupts that carry no binding this client understands now surface as
      kind: 'unbound' with canResolve: false, instead of being given a
      synthesized binding and rendered as resolvable generic interrupts. Resolving
      those produced an answer submitted against a run with nothing pending, which
      failed as unknown-interrupt only after the user had filled in the form.
      Unbound items never block submission of the interrupts that are yours.
    • The binding carries a wire version (INTERRUPT_BINDING_VERSION). Readers
      reject a version they don't recognise rather than duck-typing its fields. A
      binding written before the field existed is still read.
    • INTERRUPT_BINDING_METADATA_KEY, withInterruptBinding() and
      readInterruptBinding() are exported, so anything producing an interrupt this
      package must later resume attaches the binding through a supported API
      instead of copying the metadata key.
    • Interrupt classification is driven by the binding alone. Interrupt.reason is
      free-form AG-UI text another producer can also use, so it is now a display
      hint only and never decides ownership.
    • The interrupt protocol surface is enumerated instead of export *. The
      unimplemented durable-recovery contract (InterruptRecoveryStateV1,
      InterruptRecoveryQuery, the never-called loadInterruptState adapter hook,
      and the persistence-required / atomic-commit-unsupported /
      recovery-unavailable error codes) is removed rather than published.

  • #970 3301398 - Interrupts: the application owns wire-schema validation, and the hashing
    dependency is gone.

    The library no longer transforms a generic interrupt's wire JSON Schema into a
    validator or validates the resolved value against it, on either the client or
    the server. Whatever you pass to resolveInterrupt (client) or send in the
    resume batch (server) flows through as-is. Validate it yourself if you need to
    trust it, e.g. with z.fromJSONSchema(interrupt.responseSchema).safeParse(value)
    on the client and your own check on the server. Validation of a tool's
    code-authored Standard Schema (approvalSchema / inputSchema) is unchanged.

    This drops the ajv and ajv-formats dependencies. Interrupt binding hashes and
    resolution fingerprints now use a small bundled SHA-256 instead of
    @noble/hashes, so that dependency is gone too. The wire hash shape
    (sha256:<hex>) is unchanged.

  • #955 7c7aa09 - Resumable streams: reconnect to an in-flight SSE or NDJSON response without
    re-running the provider.

    toServerSentEventsResponse and toHttpResponse both accept a
    durability: { adapter, batch } option. The adapter (StreamDurability)
    records every chunk to an ordered log before delivery and tags each event with
    an opaque, adapter-owned offset — an SSE id: line, or the id of an NDJSON
    { id, chunk } envelope (NDJSON has no native event-id). A reconnect
    (Last-Event-ID) or an explicit ?offset read replays strictly after that
    offset from the log — the lazy provider stream is never iterated on resume.
    Producers terminalize the log on cancellation and failure (RUN_ERROR append

    • close()) and on completion when the source stream emits its own terminal
      event (chat() always does), so readers are never parked on a dead run.

    Two adapters ship: memoryStream(request) in @tanstack/ai (process-local,
    for development and tests) and the new @tanstack/ai-durable-stream package,
    a Durable Streams protocol adapter for production backends.

    For the GET handler that a reload or a second tab reconnects to,
    resumeServerSentEventsResponse({ adapter }) and resumeHttpResponse({ adapter })
    replay a run straight from the durability log. They need no producer stream and
    return a 400 when the request carries no resume offset.

    On the client, all four HTTP adapters are now resumable — fetchServerSentEvents,
    fetchHttpStream, xhrServerSentEvents, and xhrHttpStream. Each tracks the
    per-event offset, auto-reconnects with Last-Event-ID, de-duplicates the
    replayed prefix, and exposes joinRun(runId) to attach to an in-flight or
    finished run from the start (read-only GET with offset=-1). Untagged streams
    behave exactly as before. A durable run that ends with no terminal event and no
    forward progress now throws DurableStreamIncompleteError instead of hanging.

    Reconnection and durability are bounded so failures surface rather than hang or
    loop:

    • memoryStream evicts completed logs after a grace window (unbounded growth
      is gone); resuming an expired/unknown run throws, and a from-start join to a
      run that never produces fails after MemoryStreamOptions.firstChunkDeadlineMs.
    • all four HTTP adapters accept reconnect: { maxAttempts, delayMs } — a
      throttle plus a ceiling on CONSECUTIVE no-progress reconnects (default 5;
      forward progress resets it) that fails with the new StreamReconnectLimitError
      instead of reconnecting endlessly, without penalizing a healthy long-lived run.
    • durableStream accepts reconnect: { maxReadFailures, delayMs } to bound its
      read-retry loop, and server is now optional when fetch is provided (e.g. a
      Cloudflare service binding).
    • toServerSentEventsResponse accepts debug to record durability terminal /
      close failures server-side, where a replaying joiner cannot observe them.

Patch Changes

@tanstack/ai-durable-stream@0.1.0

Minor Changes

  • #955 7c7aa09 - Resumable streams: reconnect to an in-flight SSE or NDJSON response without
    re-running the provider.

    toServerSentEventsResponse and toHttpResponse both accept a
    durability: { adapter, batch } option. The adapter (StreamDurability)
    records every chunk to an ordered log before delivery and tags each event with
    an opaque, adapter-owned offset — an SSE id: line, or the id of an NDJSON
    { id, chunk } envelope (NDJSON has no native event-id). A reconnect
    (Last-Event-ID) or an explicit ?offset read replays strictly after that
    offset from the log — the lazy provider stream is never iterated on resume.
    Producers terminalize the log on cancellation and failure (RUN_ERROR append

    • close()) and on completion when the source stream emits its own terminal
      event (chat() always does), so readers are never parked on a dead run.

    Two adapters ship: memoryStream(request) in @tanstack/ai (process-local,
    for development and tests) and the new @tanstack/ai-durable-stream package,
    a Durable Streams protocol adapter for production backends.

    For the GET handler that a reload or a second tab reconnects to,
    resumeServerSentEventsResponse({ adapter }) and resumeHttpResponse({ adapter })
    replay a run straight from the durability log. They need no producer stream and
    return a 400 when the request carries no resume offset.

    On the client, all four HTTP adapters are now resumable — fetchServerSentEvents,
    fetchHttpStream, xhrServerSentEvents, and xhrHttpStream. Each tracks the
    per-event offset, auto-reconnects with Last-Event-ID, de-duplicates the
    replayed prefix, and exposes joinRun(runId) to attach to an in-flight or
    finished run from the start (read-only GET with offset=-1). Untagged streams
    behave exactly as before. A durable run that ends with no terminal event and no
    forward progress now throws DurableStreamIncompleteError instead of hanging.

    Reconnection and durability are bounded so failures surface rather than hang or
    loop:

    • memoryStream evicts completed logs after a grace window (unbounded growth
      is gone); resuming an expired/unknown run throws, and a from-start join to a
      run that never produces fails after MemoryStreamOptions.firstChunkDeadlineMs.
    • all four HTTP adapters accept reconnect: { maxAttempts, delayMs } — a
      throttle plus a ceiling on CONSECUTIVE no-progress reconnects (default 5;
      forward progress resets it) that fails with the new StreamReconnectLimitError
      instead of reconnecting endlessly, without penalizing a healthy long-lived run.
    • durableStream accepts reconnect: { maxReadFailures, delayMs } to bound its
      read-retry loop, and server is now optional when fetch is provided (e.g. a
      Cloudflare service binding).
    • toServerSentEventsResponse accepts debug to record durability terminal /
      close failures server-side, where a replaying joiner cannot observe them.

Patch Changes

@tanstack/ai-preact@0.12.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-react@0.19.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-solid@0.16.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-svelte@0.16.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-vue@0.16.0

Minor Changes

  • #970 3301398 - Adopt the AG-UI interrupt lifecycle for tool approvals, generic responses, and
    client-tool execution, with typed bound resolvers, atomic batches, and
    structured errors. Interrupts run ephemerally by resuming from the full client
    message history in a fresh child run — no persistence required.

    This changes native approval and client-tool streams from legacy custom events
    to snapshot-plus-RUN_FINISHED interrupt outcomes. Deprecated
    pendingInterrupts, addToolApprovalResponse, raw resumeInterrupts, and
    legacy event readers remain as limited compatibility surfaces for migration;
    addToolResult remains supported.

Patch Changes

@tanstack/ai-acp@0.2.4

Patch Changes

@tanstack/ai-anthropic@0.16.4

Patch Changes

@tanstack/ai-bedrock@0.1.5

Patch Changes

@tanstack/ai-claude-code@0.2.4

Patch Changes

@tanstack/ai-code-mode@0.3.9

Patch Changes

@tanstack/ai-code-mode-skills@0.3.12

Patch Changes

@tanstack/ai-codex@0.2.4

Patch Changes

@tanstack/ai-devtools-core@0.4.25

Patch Changes

@tanstack/ai-elevenlabs@0.2.35

Patch Changes

@tanstack/ai-fal@0.9.13

Patch Changes

@tanstack/ai-gemini@0.20.2

Patch Changes

@tanstack/ai-grok@0.14.10

Patch Changes

@tanstack/ai-grok-build@0.2.4

Patch Changes

@tanstack/ai-groq@0.5.4

Patch Changes

@tanstack/ai-isolate-cloudflare@0.2.39

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-code-mode@0.3.9

@tanstack/ai-isolate-node@0.1.48

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-code-mode@0.3.9

@tanstack/ai-isolate-quickjs@0.1.48

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-code-mode@0.3.9

@tanstack/ai-mcp@0.2.6

Patch Changes

@tanstack/ai-mistral@0.2.4

Patch Changes

@tanstack/ai-ollama@0.8.17

Patch Changes

@tanstack/ai-openai@0.17.2

Patch Changes

@tanstack/ai-opencode@0.2.4

Patch Changes

@tanstack/ai-openrouter@0.15.11

Patch Changes

@tanstack/ai-react-ui@0.8.16

Patch Changes

@tanstack/ai-sandbox@0.2.5

Patch Changes

@tanstack/ai-sandbox-cloudflare@0.2.5

Patch Changes

@tanstack/ai-solid-ui@0.7.15

Patch Changes

@tanstack/ai-vue-ui@0.2.35

Patch Changes

  • Updated dependencies [3301398]:
    • @tanstack/ai-vue@0.16.0

@tanstack/openai-base@0.9.10

Patch Changes

@tanstack/preact-ai-devtools@0.1.68

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.25

@tanstack/react-ai-devtools@0.2.68

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.25

@tanstack/solid-ai-devtools@0.2.68

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.25

ag-ui@0.0.3

Patch Changes

  • Updated dependencies [3301398, 3301398, 3301398, 7c7aa09]:
    • @tanstack/ai-client@0.23.0
    • @tanstack/ai-react@0.19.0
    • @tanstack/ai-react-ui@0.8.16

@github-actions
github-actions Bot force-pushed the changeset-release/main branch 4 times, most recently from e85628c to ea2c961 Compare July 22, 2026 11:42
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from ea2c961 to 9c1e3ad Compare July 22, 2026 14:32
@maxpaleo

maxpaleo commented Jul 22, 2026

Copy link
Copy Markdown

Thanks for the work on this release. Is there an approx publication window for the package versions in this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@maxpaleo