yuluo-yx opened a new issue, #10879: URL: https://github.com/apache/rocketmq/issues/10879
### Before Creating the Bug Report - [x] I found a bug, not just a question. - [x] I searched open GitHub Issues and pull requests and found no duplicate. - [x] I confirmed that this bug belongs to Apache RocketMQ. ### Runtime platform environment macOS (Darwin), reproduced with an isolated local unit test. ### RocketMQ version Branch: develop Git commit: fd0c95920e0deac96ce2ae27442747cc5e65e930 ### JDK Version Zulu OpenJDK 8 (8.94.0.17) ### Describe the Bug DefaultMetadataStore.updateTopic refreshes the update timestamp on the currently stored metadata object, then replaces the map entry with the caller-provided TopicMetadata. When the caller supplies a distinct replacement object, the stored object keeps its stale timestamp. ### Steps to Reproduce 1. Add topic metadata to DefaultMetadataStore. 2. Create a distinct TopicMetadata replacement for the same topic with updateTimestamp set to 0. 3. Call updateTopic with the replacement. 4. Read the metadata back from the store. ### What Did You Expect to See? The replacement object stored in the table should have a fresh positive update timestamp. ### What Did You See Instead? The replacement is stored with updateTimestamp still equal to 0; only the discarded old object was refreshed. ### Additional Context The behavior is deterministic in DefaultMetadataStoreTest. -- 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]
