Aias00 opened a new issue, #7228: URL: https://github.com/apache/rocketmq-dashboard/issues/7228
### Before Creating the Bug Report - [x] Searched existing issues and PRs, including session timestamp/timezone work (#5886), idle-timeout work (#5303/#5484), and session overview tests. None protects last_seen_at against out-of-order concurrent refreshes. - [x] This is a Studio defect on the current development branch. ### Studio Version `rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from source. ### Runtime Environment macOS, JDK 21; database regression can run with the H2 dev profile. No browser or live broker required. ### Connected RocketMQ Cluster Not required; Studio session persistence only. ### Describe the Bug `AuthService.databaseUserForToken` decides from a previously read session whether to refresh last_seen_at, then writes the request's captured time using only the session ID in its WHERE clause. Two concurrent requests can both qualify: the newer refresh commits first, then a delayed older request overwrites it with an earlier time. ### Steps to Reproduce 1. Persist an enabled user and a valid session whose last_seen_at is older than the five-minute refresh interval. 2. Begin authenticating the token at T1, pausing just before its UPDATE. 3. Authenticate the same token at T2 > T1, allowing that refresh to commit. 4. Resume the T1 UPDATE and inspect last_seen_at and the user/session overview. ### What Did You Expect to See? The stored last-seen timestamp stays at T2. A delayed request cannot move session activity backwards. ### What Did You See Instead? The unconditional refresh can replace T2 with T1, making lastSessionSeenAt/idleSeconds/stale summaries underreport real activity. This is observable in the current overview; no proposed idle-timeout feature is required to reproduce it. ### Additional Context Make the refresh conditional on the persisted timestamp still being null or earlier than the candidate time. Preserve the existing five-minute write throttle. ### Are You Willing to Submit a Pull Request? - [x] Yes -- 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]
