withPersistence does not save activity rows when a run is stopped or fails
Los mantenedores suelen responder en 1 día
@tombeckenham ya está trabajando en esto.
Desde el 16/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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:
- Install
@tanstack/[email protected]and@tanstack/[email protected]. - Save the script below as
repro.mjsin an ESM package and runnode 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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3.2k
- Forks
- 365
- Merge medio
- 1 d 9 h
- PR fusionados (30 d)
- 242
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/ai
-
Activity events that a chat middleware emits are streamed but never recorded or persistedPosiblemente ocupada @AlemTuzlak la tomó hace 3 días. Abiertowaiting-on: maintainer
TanStack/ai#1803 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
withPersistence stores the durability batch hint on a stopped or failed assistant messagePosiblemente ocupada @tombeckenham la tomó hace 3 días. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1802 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Discriminate status-dependent record and option types (RunRecord, SessionIndexEntry, InputState, durable-only options)Posiblemente ocupada @jherr la tomó hace 3 días. Abiertoenhancement waiting-on: maintainer
TanStack/ai#1799 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-harness: an input with no principal runs with the owner session's principalPosiblemente ocupada @tombeckenham la tomó hace 4 días. Abiertowaiting-on: maintainer
TanStack/ai#1797 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-harness: a forwarded command completes with no result, also when the owner rejects itPosiblemente ocupada @tombeckenham la tomó hace 4 días. Abiertowaiting-on: maintainer
TanStack/ai#1796 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/ai
Issues similares
-
Add: Tequila Music TV RO SDAbiertocheck:passed streams:add
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
iptv-org/iptv#55821 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
vercel-labs/wterm#246 ·
Los mantenedores suelen responder en 1 día
-
bug ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
nearform/lastlight#452 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
fix(console): include PARTITIONED BY in generated table DDLPosiblemente ocupada @aubdiy la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/polaris-tools#291 ·
Los mantenedores suelen responder en 6 días