Activity events that a chat middleware emits are streamed but never recorded or persisted
Los mantenedores suelen responder en 1 día
@AlemTuzlak 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
An ACTIVITY_SNAPSHOT (or ACTIVITY_DELTA) that a chat middleware returns from onChunk reaches the client live, but the engine does not record it in ctx.activities. withPersistence therefore never saves it, and reconstructChat returns no activity row for it after a reload. The same event yielded by the adapter is recorded, saved and restored.
Activity rows and the activities store came in #1323 (issue #1286).
The cause is the order in the chat engine. In packages/ai/src/activities/chat/index.ts, each adapter chunk goes through handleStreamChunk(raw) before middleware runs. handleStreamChunk is the only place that applies ACTIVITY_SNAPSHOT / ACTIVITY_DELTA to the activity records (setActivities). Chunks that middleware adds go through emitPublicChunks, which normalizes and yields them but does not apply activity events. withPersistence saves ctx.activities, so it only ever sees adapter activity.
This is about the activity store (stores.activities, which withPersistence writes from ctx.activities and reconstructChat reads). It is not about the durability log, the delivery stream that toServerSentEventsResponse({ durability }) appends to. From the code, the middleware chunk is on the public stream, so I expect the durability log to carry it like any other chunk. I did not test that. The gap is that reconstructChat has no row for it.
The docs in docs/persistence/chat-persistence.md ("AG-UI activity rows on reload") present activity rows as the place for "a search progress card", and say withPersistence and reconstructChat "save and restore the rows when stores.activities is set". docs/advanced/middleware.md documents that onChunk can return StreamChunk[] to add chunks. A progress card is often made by middleware (for example, middleware that wraps a search tool), not by the provider adapter, so the two documented features do not work together today.
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, defineChatMiddleware } from '@tanstack/ai'
import { memoryPersistence, reconstructChat, withPersistence } from '@tanstack/ai-persistence'
const progress = {
type: 'ACTIVITY_SNAPSHOT',
messageId: 'search-1',
activityType: 'search',
content: { status: 'done', hits: 3 },
timestamp: Date.now(),
}
function adapter(withActivity) {
return {
kind: 'text',
name: 'fixed',
model: 'test-model',
'~types': {},
async *chatStream({ threadId, runId }) {
const t = Date.now()
yield { type: 'RUN_STARTED', threadId, runId, timestamp: t }
if (withActivity) yield progress
yield { type: 'TEXT_MESSAGE_START', messageId: 'msg-1', role: 'assistant', timestamp: t }
yield { type: 'TEXT_MESSAGE_CONTENT', messageId: 'msg-1', delta: 'answer', timestamp: t }
yield { type: 'TEXT_MESSAGE_END', messageId: 'msg-1', timestamp: t }
yield { type: 'RUN_FINISHED', threadId, runId, finishReason: 'stop', timestamp: t }
},
}
}
// The same activity, produced by a middleware instead of the adapter.
const searchProgress = defineChatMiddleware({
name: 'search-progress',
onChunk(ctx, chunk) {
if (chunk.type === 'TEXT_MESSAGE_START') return [progress, chunk]
},
})
async function run(label, fromMiddleware) {
const persistence = memoryPersistence()
const threadId = `thread-${label}`
const stream = chat({
adapter: adapter(!fromMiddleware),
messages: [{ role: 'user', content: 'search' }],
threadId,
runId: `run-${label}`,
middleware: [
withPersistence(persistence),
...(fromMiddleware ? [searchProgress] : []),
],
})
const wire = []
for await (const chunk of stream) wire.push(chunk.type)
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)
console.log(' ACTIVITY_SNAPSHOT on the stream:', wire.includes('ACTIVITY_SNAPSHOT'))
console.log(' stored activities:', JSON.stringify(stored))
console.log(' reconstructChat roles:', JSON.stringify(roles))
}
await run('from adapter', false)
await run('from middleware', true)
Expected
The activity row is stored and restored in both runs:
from adapter
ACTIVITY_SNAPSHOT on the stream: true
stored activities: [{"id":"search-1","activityType":"search","content":{"status":"done","hits":3},"index":1}]
reconstructChat roles: ["user","activity","assistant"]
from middleware
ACTIVITY_SNAPSHOT on the stream: true
stored activities: [{"id":"search-1", ...}]
reconstructChat roles: ["user","activity","assistant"]
Actual
from adapter
ACTIVITY_SNAPSHOT on the stream: true
stored activities: [{"id":"search-1","activityType":"search","content":{"status":"done","hits":3},"index":1}]
reconstructChat roles: ["user","activity","assistant"]
from middleware
ACTIVITY_SNAPSHOT on the stream: true
stored activities: []
reconstructChat roles: ["user","assistant"]
The expected contract, from the docs above, is that an activity event on the stream is saved and restored no matter which layer added it. A possible fix is to apply ACTIVITY_SNAPSHOT / ACTIVITY_DELTA to ctx.activities for middleware output in emitPublicChunks too. If activity rows are meant to come only from adapters, the activity docs should say so.
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
-
withPersistence does not save activity rows when a run is stopped or failsPosiblemente ocupada @tombeckenham la tomó hace 3 días. Abiertowaiting-on: maintainer
TanStack/ai#1804 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
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
Todos los issues de TanStack/ai
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
radix-ui/primitives#4228 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
SignalK/freeboard-sk#1093 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
[测试] 等待仓库加载后再记录多仓库排序基线Posiblemente ocupada @myot233 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día