unbridled-41 opened a new issue, #11037: URL: https://github.com/apache/rocketmq/issues/11037
### Before Creating the Bug Report - [X] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [X] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [X] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment Linux, JDK 21, develop (ff8f6f74c) ### RocketMQ version 5.x develop ### Describe the Bug ScheduleMessageService#messageTimeUp (broker/src/main/java/org/apache/rocketmq/broker/schedule/ScheduleMessageService.java) encodes the delivered message's `propertiesString` **before** the internal properties are cleared: ```java msgInner.setPropertiesString(MessageDecoder.messageProperties2String(msgExt.getProperties())); // line 344 — encode ... MessageAccessor.clearProperty(msgInner, MessageConst.PROPERTY_DELAY_TIME_LEVEL); // line 353 — clear after MessageAccessor.clearProperty(msgInner, MessageConst.PROPERTY_TIMER_DELIVER_MS); MessageAccessor.clearProperty(msgInner, MessageConst.PROPERTY_TIMER_DELAY_SEC); ``` The `propertiesString` is what actually gets persisted in the commitlog and decoded on the consumer side, so every delay-level message delivered by `ScheduleMessageService` still carries `DELAY_TIME_LEVEL` (and `TIMER_DELIVER_MS`/`TIMER_DELAY_SEC` when the producer used timer properties) on the wire, while the broker-side property map no longer has them. The property map and the wire data disagree; SQL92 property filtering and user code see stale internal properties. This is the exact defect class fixed for the timer-wheel path in #10972 / commit e533b663f (`TimerMessageStore#convertMessage` now encodes **after** clearing). The same pattern in `ScheduleMessageService#messageTimeUp` predates it (old unmerged PR #4190 tried to address it in 2022) and was not covered by that fix. ### Steps to Reproduce 1. Send a message with `setDelayTimeLevel(n)`. 2. When the delay expires, `messageTimeUp` re-writes it into the real topic. 3. Consume the message: `message.getProperties()` / `getProperty("DELAY_TIME_LEVEL")` (decoded from `propertiesString`) still returns the internal delay properties. ### Expected Behavior The delivered message's `propertiesString` must be encoded after the internal properties are cleared, so the property map and the wire data are consistent and no internal properties leak to consumers. -- 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]
