withPersistence does not save activity rows when a run is stopped or fails

TanStack AI version

@tanstack/ai 0.69.0, @tanstack/ai-persistence 0.9.0 (the same behavior is on main at 85c2956)

Framework/Library version

Node 26.3.1, server only (no UI framework involved)

Describe the bug and the steps to reproduce it

With an activities store, withPersistence saves AG-UI activity rows when a run finishes, but not when the run is stopped or fails. After a reload, reconstructChat returns no activity row for a stopped or failed run, even though the client showed it live.

Activity rows and the activities store came in #1323 (issue #1286).

In packages/ai-persistence/src/middleware.ts, persistActivities(ctx) runs in onStart, in the throttled text snapshot (only with snapshotStreaming), at an interrupt, and in onFinish. onError and onAbort call updateStreamingRows and failRun / abortRun, but not persistActivities. So a stopped or failed run keeps only the activity state of the last text snapshot. Without snapshotStreaming, or when no text was streamed after the activity, it keeps none of the activity from that run.

This is about the activity store (stores.activities, which withPersistence writes and reconstructChat reads). It is not about the durability log, the delivery stream that toServerSentEventsResponse({ durability }) appends to. The message store (stores.messages) does mark the stopped or failed assistant row through updateStreamingRows. Only the activity rows are left behind.

A progress row is most useful on exactly these runs. For example, a search card that says "searching" or "found 3 sources" is the only trace of the work when the user presses Stop or the provider fails.

Steps:

1. Install @tanstack/[email protected] and @tanstack/[email protected].
2. Save the script below as repro.mjs in an ESM package and run node repro.mjs.

repro.mjs:

import { chat } from '@tanstack/ai'
import { memoryPersistence, reconstructChat, withPersistence } from '@tanstack/ai-persistence'

async function run(label, end) {
  const persistence = memoryPersistence()
  const controller = new AbortController()
  const threadId = `thread-${label}`
  const adapter = {
    kind: 'text',
    name: 'fixed',
    model: 'test-model',
    '~types': {},
    async *chatStream({ runId }) {
      const t = Date.now()
      yield { type: 'RUN_STARTED', threadId, runId, timestamp: t }
      yield {
        type: 'ACTIVITY_SNAPSHOT',
        messageId: 'search-1',
        activityType: 'search',
        content: { status: 'running' },
        timestamp: t,
      }
      if (end === 'stop') controller.abort() // the user presses Stop
      if (end === 'error') throw new Error('provider failed')
      yield { type: 'RUN_FINISHED', threadId, runId, finishReason: 'stop', timestamp: t }
    },
  }
  const stream = chat({
    adapter,
    messages: [{ role: 'user', content: 'search' }],
    threadId,
    runId: `run-${label}`,
    abortController: controller,
    middleware: [withPersistence(persistence)],
  })
  try {
    for await (const _ of stream) void _
  } catch {}
  const stored = await persistence.stores.activities.loadActivities(threadId)
  const res = await reconstructChat(persistence, new Request(`https://x/chat?threadId=${threadId}`))
  const roles = (await res.json()).messages.map((m) => m.role)
  console.log(`${label}: stored activities ${stored.length}, reconstructChat roles ${JSON.stringify(roles)}`)
}

await run('finish', 'finish')
await run('stop', 'stop')
await run('error', 'error')

Expected

finish: stored activities 1, reconstructChat roles ["user","activity"]
stop: stored activities 1, reconstructChat roles ["user","activity"]
error: stored activities 1, reconstructChat roles ["user","activity"]

Actual

finish: stored activities 1, reconstructChat roles ["user","activity"]
stop: stored activities 0, reconstructChat roles ["user"]
error: stored activities 0, reconstructChat roles ["user"]

(The error run also logs the expected chat run failed error. It is left out above.)

A likely fix is to call persistActivities(ctx) in onError and in the terminal branch of onAbort, after failRun / abortRun, so the run record is terminal first. A plain disconnect on a detachable or interrupted run would stay as it is now (nothing written).

One limit applies. persistActivities catches a rejected save, so a failing activity store cannot change how the run ends. It still awaits the save, though. A save that hangs would hold up the hook, and with it the completion promise (waitForRunCompletion) if the save runs before that promise is rejected. onFinish has the same exposure today, because it awaits persistActivities before it resolves the completion. If that matters here, the save could run after the completion promise settles, or take a timeout.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

Inline above. Plain Node script, no network, no model.

Screenshots or Videos (Optional)

None.

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.