lizhimins commented on PR #4651:
URL:
https://github.com/apache/rocketmq-dashboard/pull/4651#issuecomment-5761163840
Thanks — your analysis of the race is correct, and it is the same one we
fixed a few days ago.
**The trunk already carries this exact change.** #4501 (`fix(message):
preserve replacement queue pull locks`, opened 2026-09-17 and merged on
2026-09-21 as `c230fc989`) rewrote the same `finally` block in
`useQueueBrowser.handlePull` to
```tsx
} finally {
if (requestId === requestSeqRef.current) {
pullingRef.current.delete(key);
setPulling(new Set(pullingRef.current));
}
}
```
which is character-for-character your production change; the only difference
in the whole file is the four-line explanatory comment you added. The reasoning
in that commit message is the same as yours — a request from a previous
generation could delete the lock belonging to the request that replaced it, so
the lock is only released when the finishing request is still the current one,
matching the two other request-sequence guards in the hook. #4501 also added 31
lines to `web/src/components/__tests__/QueueBrowser.test.tsx`, so the
stale-pull case you wrote a test for is already pinned there.
Two mechanical consequences of that:
- Your branch is based on `master` (merge-base `d50ffecc9`), which predates
the merge, so `git merge-tree` against `rocketmq-studio` reports a content
conflict in `QueueBrowser.tsx`. All Studio PRs now target the `rocketmq-studio`
branch.
- Because the guarded `finally` is already on trunk, no line of this PR can
be reverted to make a trunk test fail — there is no remaining delta to guard.
#4501 was also opened three and a half days before this PR (2026-09-17 09:04
UTC against 2026-09-21 00:43 UTC), so it wins on first-come order as well.
Closing as already covered — there is genuinely nothing left to take here, and
the comment text alone is not worth a follow-up round.
If you are looking for somewhere to put this kind of attention, the
request-sequence guards in the web layer are a good place to go hunting: the
pattern is consistent now, but pages added before it are worth checking against
it.
--
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]
