lizhimins commented on PR #5785: URL: https://github.com/apache/rocketmq-dashboard/pull/5785#issuecomment-6093315930
> The defect is real and the scoping is complete: on trunk only `activeRun` was ownership-checked (`useConversationTimeline.ts:227-231`), so a pending or failed switch to another conversation kept rendering the previous transcript and let `loadMore` issue a request for the new conversation using the previous one's `nextAfter` cursor. Routing `items`, `bubbles`, `lastSeq`, `hasMore` and the `loadMore` guard through one `ownsSnapshot` predicate is the right shape, and the third case correctly pins that a failed same-conversation refresh still keeps its snapshot. > > We also checked the interaction with `12b63f34` (#5440), which landed on trunk after your base and now feeds `timeline.lastSeq` into `attach()` at `useActiveRunAttach.ts:73`: since that effect requires `activeRun !== null` and trunk already narrows `activeRun` by the same ownership condition, zeroing `lastSeq` cannot cause a duplicate replay. No regression there. > > The blocker is ownership, not quality: #5786 fixes the same issue (#5780) and genuinely conflicts in `useConversationTimeline.ts`. #5786 is based on a newer trunk and adds six regressions including the positive "pagination still works after a successful switch" path. We will pick one and close the other with a pointer. --- **Decision**: we are taking #5786 - newer baseline, and it adds six regressions including the positive "pagination still works after a successful switch" path. Closing this one as a duplicate, as promised above. Thanks for the thorough scoping of the five leaking fields. -- 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]
