ai-yang opened a new issue, #734: URL: https://github.com/apache/rocketmq-dashboard/issues/734
## Affected branch `rocketmq-studio` at `bbf1b7e0cf25a5065ba049b5450cc8155569f710` ## Problem The message page applies asynchronous query and trace responses without checking whether the request still owns the corresponding UI state. This causes two related stale-response paths in `web/src/pages/instance/message.tsx`: 1. `handleReset()` clears the table but does not invalidate an in-flight `queryMessages()` call. A late response repopulates the table after the user reset it. 2. Closing message A's detail and opening message B starts a second `getMessageTrace()` call, but a late response for A can overwrite B's already displayed trace. ## Deterministic reproduction ### Query after reset 1. Make `queryMessages()` return a controlled pending Promise. 2. Start a query. 3. Click Reset while the Promise is pending. 4. Resolve it with a record named `late-after-reset`. Expected: the table stays empty because Reset invalidated the request. Actual: `late-after-reset` appears in the table. ### Trace after switching messages 1. Return messages A and B from the query. 2. Open A's trace and keep its trace Promise pending. 3. Close A and open B. 4. Resolve B's trace, then resolve A's trace. Expected: B's trace remains displayed. Actual: A's late trace replaces B's trace while the dialog still belongs to B. The controlled regression tests are: ```text MessagePage async request ownership > does not restore query results after the user resets an in-flight query MessagePage async request ownership > does not display a late trace from a previously closed message detail ``` Both business assertions failed in each of 5/5 isolated Vitest processes on the unmodified branch under Node 20.19.5. The tests use controlled Promises only, without timers, fixed sleeps, random scheduling, network access, or external services. This test file was executed separately from the LLM settings regression file so their mocks and component state could not interfere. ## Impact Operators can see results that no longer match the current form state or trace data belonging to a different message. That can lead to incorrect troubleshooting conclusions. The default backend provider currently returns empty stub data as tracked by #684, so the visible production path depends on a real/custom provider or resolution of #684. The frontend state bug is independent of the provider implementation. ## Suggested fix - Track a monotonically increasing request generation (or equivalent ownership token) separately for message queries and traces. - Invalidate the query generation on Reset and unmount. - Invalidate the trace generation when closing the dialog, opening another message, and unmounting. - Apply loading, success, error, and `finally` state only when the completing request still owns the current generation. - Keep the two controlled-Promise regression tests. The expected production change is limited to `web/src/pages/instance/message.tsx`, with regression coverage in `web/src/pages/instance/__tests__/MessagePageAsyncState.test.tsx`. ## Related work checked - #684 tracks the production `MessageProviderStub` returning empty results; it does not handle frontend request ownership. - Merged PR #445 connected the page to the backend APIs, and merged PR #526 added message/trace DTOs. Closed, unmerged PR #530 proposed request DTOs. None adds frontend request ownership. - Historical issues #94 and #190 report trace-query failures, not a late response being applied to another open message. Searches across open and closed issues, plus open/closed/merged pull requests, covered `MessagePage`, `message.tsx`, `queryMessages`, `getMessageTrace`, query Reset, message-detail trace dialogs, late/stale responses, and request races. No equivalent frontend report, fix, or claimed work was found. -- 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]
