Aias00 opened a new issue, #4526: URL: https://github.com/apache/rocketmq-dashboard/issues/4526
### Before Creating the Bug Report - [x] I searched open and closed issues and pull requests for System Alert filter loading, stale event rows, pending acknowledgement, and feed refresh behavior. - [x] I verified the behavior on current `master` (`987b748e8f4f421c5cd3c4c4e51a064cc7e59f18`). ### Problem The System Alerts page initializes `loading=true`, but its server-page effect never sets loading back to true when the level, domain, transition, suppression, instance, label, time, pagination, or refresh dependencies change. The request completion path only sets loading to false. After the initial load, changing any filter or page leaves the previous alert feed rendered as if it matched the new query. Acknowledgement, delivery-record, related-event, root-cause, and delivery-retry actions on those stale events remain reachable while the replacement request is pending. The effect cleanup already prevents an older response from publishing after dependencies change. This is not a response-order race; it is a missing loading and interaction boundary for the current request. ### Impact During incident triage, operators can acknowledge or inspect an event that is no longer part of the active query. The screen also temporarily presents the previous result set and counts as current, which can mislead filtering and pagination decisions. ### Proposed Design Keep the existing request effect and cancellation behavior: 1. Re-enter `loading=true` whenever the System Alert page request starts. 2. Reuse the existing render behavior: while loading, show the loading Card and do not render the previous alert feed or its row actions. 3. Preserve the current stale-response cancellation and collector-status request. 4. Do not add input debounce or change backend APIs in this fix. Because the frontend lint rule rejects synchronous state writes at the top of an effect, schedule the loading transition with a guarded microtask and check the existing `cancelled` flag before updating state. ### Acceptance Criteria - Filter, page, and refresh changes enter the loading state until the current request settles. - Events from the previous query and their actions are not rendered while replacement data is pending. - Loading clears on both success and failure for the current request. - Superseded responses remain unable to publish. - A genuine empty result still renders the normal empty state after loading completes. - A deferred-promise regression fails on current master and passes after the fix. - Focused tests, the frontend suite, lint, build, formatting, and `git diff --check` pass. AI-assisted source audit; behavior was verified from the current effect, conditional feed rendering, and event action controls. -- 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]
