Loyal-Young opened a new pull request, #5368: URL: https://github.com/apache/rocketmq-dashboard/pull/5368
### Which Issue(s) This PR Fixes - Fixes #5367 ### Brief Description On a System Alert with two failed notification deliveries, the operator could retry both while the first delivery-detail reload was still pending. The second retry succeeded, but its forced reload returned early because the first reload held the loading flag. The card then showed the older snapshot. Forced reloads now start a new request. A per-alert request generation lets only the newest response update delivery details, report a load error, or clear the spinner. Ordinary repeated Delivery Records clicks still share the existing in-flight read. ### Verification - The new regression fails on the unmodified code: after retrying deliveries 9 and 10, `listAlertDeliveries` is called only twice rather than three times. With the fix, the second reload starts and a slower first response cannot overwrite its result. - `cd web && node node_modules/vitest/vitest.mjs run src/pages/ops/__tests__/SystemAlertsPage.test.tsx --pool=threads --maxWorkers=1 --reporter=dot` — 19 tests passed. - `cd web && node node_modules/eslint/bin/eslint.js src/pages/ops/systemAlerts.tsx src/pages/ops/__tests__/SystemAlertsPage.test.tsx` — 0 errors; one pre-existing `react-hooks/exhaustive-deps` warning on line 229. - `cd web && node node_modules/typescript/bin/tsc -p tsconfig.app.json --noEmit --pretty false` — passed. - `git diff --check` — passed. ### AI Assistance AI assistance helped trace the retry and reload flow and draft the overlapping-request regression. I confirmed it failed before the production change, reviewed the request ownership logic, and ran the checks above. -- 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]
