btlqql commented on PR #4714: URL: https://github.com/apache/rocketmq-dashboard/pull/4714#issuecomment-5762571633
All three items are done, on top of `4c697f07`. **`recordSuccess` is on the same guard now.** You were right, including the reachability: fail once for your own username (creating the exact entry), then log in successfully → whole-table wipe → every other username's live overflow lock is gone. It now reads `clock.millis()` and calls `clearStaleOverflowAttempts(now)`. Two tests, one per direction: - `successfulLoginMustNotReleaseAnotherUsersOverflowLockTest` — the reachable sequence above; - `successfulLoginStillDropsOverflowStateThatCarriesNoLockTest` — the control, so the episode reset that must stay still happens. **Mutation check, scoped to that hunk alone** (the other two callers left as fixed), on the rebased tree: ``` $ mvn -B -ntp test -Dtest=LoginRateLimiterTest [ERROR] Tests run: 17, Failures: 1, Errors: 0, Skipped: 0 [ERROR] LoginRateLimiterTest.successfulLoginMustNotReleaseAnotherUsersOverflowLockTest:330 ``` The other four new tests stay green, so this case is sensitive to its own hunk and not accidentally covered by its neighbours. **The javadoc's scope sentence is gone.** You were right that "they cannot disable rate limiting" was only true once all three callers agree. The class javadoc now says a lock the overflow tracker earned outlives the saturation that created it, that all three paths freeing an exact slot only drop state carrying no lock, and it states the collision trade-off explicitly — a colliding username stays rejected for the remainder of a shared lock. Whole suite on a host with MySQL 8 reachable: 3150 tests, 0 failures, 0 errors (3145 on the untouched head). -- 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]
