unbridled-41 opened a new issue, #4279:
URL: https://github.com/apache/rocketmq-dashboard/issues/4279
## Problem / Evidence
`useQueueBrowser`（`web/src/components/QueueBrowser.tsx`）的拉取状态与请求代数在"重新加载队列"时失步：
- `loadQueues` 通过 `const requestId = ++requestSeqRef.current` 递增代数，并清空
`queues/offsets/entries`，但**不清空 `pulling` 状态**（对比 `[instanceId, topic]` 重置
effect 会同时 `pullingRef.current.clear(); setPulling(new Set())`）。
- `handlePull` 的 `finally` 块总是从 `pullingRef` 删除 key，但仅当 `requestId ===
requestSeqRef.current` 时才同步 React 状态：`if (requestId === requestSeqRef.current)
setPulling(new Set(pullingRef.current))`。
因此当一次拉取在途时再次点击"加载队列"（拉取期间按钮不禁用，`loading` 只由 loadQueues 维护），队列行 `查看` 按钮的
`loading={state.pulling.has(key)}` 永久为 true，而 ref 中已无该
key——没有任何请求在途，按钮却永久转圈。恢复只能再次点击"查看"（这会静默发起一次新的后端拉取）或切换 topic/实例。
回归测试（先红）：`clears the pulling indicator when the queue list reloads mid-pull`
在未修复代码上失败，修复后通过。
## Impact
消息页"按队列浏览"模式的核心操作陷入永久 spinner；运维人员会误以为 broker 读取卡死。恢复动作（再点一次查看）会隐式重复触发后端拉取。
## Expected behavior
重新加载队列列表应使所有在途拉取失效并同步清空拉取指示器，与 topic/实例切换时的既有重置行为一致。
## Related work
- 同文件 `[instanceId, topic]` 切换 effect 已有完整的 `pullingRef` + `setPulling`
重置（本缺陷是该模式在 reload 路径上的缺失）。
- 仓库内其余请求守卫（如 cluster 页 brokerConfigDiffRequestRef 等）均为同代数模式。
## PR
Fix incoming.
--
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]
