Activity events that a chat middleware emits are streamed but never recorded or persisted
Maintainer thường phản hồi trong vòng 1 ngày
@AlemTuzlak đang làm issue này rồi.
Từ ngày 16/10/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
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.
- Ngôn ngữ chính
- TypeScript
- Star
- 3.2k
- Fork
- 365
- Merge trung bình
- 1 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 242
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của TanStack/ai
-
withPersistence does not save activity rows when a run is stopped or failsCó thể đã có người làm @tombeckenham đã nhận 3 ngày trước. Đang mởwaiting-on: maintainer
TanStack/ai#1804 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
withPersistence stores the durability batch hint on a stopped or failed assistant messageCó thể đã có người làm @tombeckenham đã nhận 3 ngày trước. Đang mởhas-pr waiting-on: maintainer
TanStack/ai#1802 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Discriminate status-dependent record and option types (RunRecord, SessionIndexEntry, InputState, durable-only options)Có thể đã có người làm @jherr đã nhận 4 ngày trước. Đang mởenhancement waiting-on: maintainer
TanStack/ai#1799 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-harness: an input with no principal runs with the owner session's principalCó thể đã có người làm @tombeckenham đã nhận 4 ngày trước. Đang mởwaiting-on: maintainer
TanStack/ai#1797 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-harness: a forwarded command completes with no result, also when the owner rejects itCó thể đã có người làm @tombeckenham đã nhận 4 ngày trước. Đang mởwaiting-on: maintainer
TanStack/ai#1796 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256Đang mởarea: backend documentation priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
snapotter-hq/SnapOtter#2919 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
BUG: Uncaught MEMORY USAGE error on Redis < 4.0 causes keys table data load to fail entirelyĐang mởaccepted :+1: bug db/redis
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
beekeeper-studio/beekeeper-studio#4882 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ready-for-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
konflux-ci/konflux-ui#1630 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
simkimsia/netlify-axi#19 ·
Maintainer thường phản hồi trong vòng 1 ngày