Loyal-Young opened a new issue, #5367: URL: https://github.com/apache/rocketmq-dashboard/issues/5367
### Summary On the System Alerts page, an alert may have two failed notification deliveries (for example, email and DingTalk). The operator can click Retry on both while the first retry's delivery-list refresh is still pending. `handleRetryDelivery` invokes `loadDeliveries(alertId, true)` after each retry, but `loadDeliveries` returns early whenever `loadingDeliveries` already contains that alert ID—even when `force=true`. The second retry therefore queues successfully without fetching the updated list. When the older refresh finishes, the card can show stale delivery status despite both success toasts. ### Reproduction 1. Open delivery records for an alert with two failed channels. 2. Retry the first failed delivery and hold the resulting `listAlertDeliveries` response. 3. Retry the second failed delivery. Its forced reload is skipped because the first reload is in flight. 4. Resolve the first response with the earlier state. The card does not reflect the second retry. ### Expected behavior Each forced refresh after a retry should start a new read. Only the newest read for an alert should publish its result or clear its loading state, even if an older read completes last. Ordinary repeated clicks on Delivery Records can still share the existing in-flight read. ### Scope This concerns the per-alert delivery detail card in `web/src/pages/ops/systemAlerts.tsx`. Open PR #5337 concerns the separate Notification Deliveries page's filtered list; open PR #4527 concerns stale filtered-page actions. Neither handles overlapping forced detail refreshes after two retries. -- 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]
