Aias00 opened a new issue, #5584: URL: https://github.com/apache/rocketmq-dashboard/issues/5584
## Problem `useConversationTimeline` uses one shared `requestId` for both full `refetch()` calls and incremental `loadMore()` calls. Starting either operation increments the same generation, so the two independent workflows invalidate each other. A final run refresh can therefore be lost: 1. An agent run finishes and `useAgentRun` awaits `timeline.refetch()` to replace the live transcript with the persisted timeline. 2. Before the full refresh resolves, the operator clicks **Load remaining events**. 3. `loadMore()` increments the shared `requestId`. 4. The full refresh observes a stale id and returns without applying the persisted transcript. The reverse ordering also drops a valid load-more result when a refetch starts while it is in flight. Current code: `web/src/pages/ai/hooks/useConversationTimeline.ts` (`requestId` around line 108, `refetch` around lines 127-157, `loadMore` around lines 165-185). ## Root cause One counter is being used for two different guarantees: - invalidate work owned by an obsolete conversation/full reload generation; - prevent duplicate or stale incremental pagination writes. Those guarantees must not make a current full refresh and a current load-more request cancel each other. ## Proposed design 1. Keep a generation dedicated to full timeline ownership and conversation invalidation. 2. Keep load-more request ownership separate from the full refresh generation. 3. A full refetch remains authoritative: when it completes, it replaces the full transcript and supersedes any older incremental page. 4. Starting load-more must not cancel an in-flight refetch. 5. Starting refetch may invalidate an older load-more write, but must also release the load-more guard so the UI cannot remain stuck. 6. Preserve conversation-change/unmount invalidation and duplicate-load-more prevention. ## Test plan - Add a deferred-request regression where `refetch()` starts, `loadMore()` starts second, load-more resolves, then refetch resolves; assert the final state contains the authoritative full refresh. - Add the reverse ordering where load-more starts first and a refetch supersedes it; assert the stale page cannot append after the refresh. - Assert the loading state and load-more guard clear after each interleaving. - Run the focused hook tests, the full frontend suite, lint, TypeScript/build checks and `git diff --check`. ## Acceptance criteria - `loadMore()` never cancels a current `refetch()`. - A stale incremental page never appends after a newer full refresh. - Conversation changes still discard all responses owned by the previous conversation. - Duplicate load-more calls remain suppressed. Target branch: `rocketmq-studio` at `6a68042fa73a513f40436ca721944b4de48181ec`. -- 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]
