123123213weqw opened a new pull request, #5754:
URL: https://github.com/apache/rocketmq-dashboard/pull/5754
## What\n\n`AiRunService.attach` (the `GET /api/ai/runs/{runId}/stream`
reconnect path) fetched exactly one page of the timeline —
`findByConversationIdAfterSeq(..., DEFAULT_TIMELINE_LIMIT=200)` — replayed it
and moved on to tailing live frames.\n\n## Why it is a bug\n\nA tool-heavy turn
writes several rows per tool call (tool_use, tool_result, notices) plus a text
row every 2048 characters, so a run that keeps generating while the client is
reconnecting easily persists more than 200 rows past the client's cursor. Rows
beyond the first page were then stranded forever:\n\n- their live frames were
published before this observer attached, so the tail never delivers them;\n-
their seq is above the cursor the client already holds, so the client never
re-fetches them.\n\nThe transcript showed a hole in the middle of the
answer.\n\n## The fix\n\nPage the replay forward until a short page, advancing
the cursor to the last replayed seq (the session dedups against the watermark
it alrea
dy tracks). The loop is bounded at 25 pages (5,000 rows) purely as a guard
against a misbehaving repository returning endless full pages — far beyond any
real backlog.\n\n## Test\n\nRed-first:
`AiRunServiceTest.attachShouldReplayTheWholeBacklogBeyondOnePageTest` stubs a
full first page (200 rows) plus a second page carrying the tail and the
terminal row, and asserts the tail reaches the wire. Fails on the single-fetch
code, passes with the paging; the whole class (23 tests) stays green.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
