leizhiyuan opened a new issue, #1476: URL: https://github.com/apache/rocketmq-clients/issues/1476
### 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-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/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. ### Programming Language of the Client Rust ### Runtime Platform Environment Linux (any platform is affected, the bug is in the encoding logic) ### RocketMQ Version of the Client/Server Client: master, commit 98822d9fae4e1f298c4d723b6f8f54480f19297e (the bug exists since the message id generator was added in #471) Server: 5.x ### Run or Compiler Version _No response_ ### Describe the Bug The Rust client writes the time field of a V1 message id in the wrong unit and from the wrong epoch, so the broker / dashboard decodes the message id to a time in the future (e.g. year 2032). All clients generate a 17-byte V1 message id (34 hex chars): ``` 0x01 | MAC (6) | PID lower 2 bytes (2) | time (4) | sequence (4) ``` Java (`MessageIdCodec`), Go, Python, C#, C++ and Node.js all write **the lower 4 bytes of the seconds since 2021-01-01 00:00:00 UTC** into the time field, as documented in the header comment of `rust/src/model/message_id.rs` itself. The Rust implementation instead writes **milliseconds since the start of the current month**, which is the semantics of the legacy 4.x `MessageClientIDSetter` (it was "inspired by https://github.com/messense/rocketmq-rs";): ```rust buf.write_i32::<BigEndian>( ((OffsetDateTime::now_utc().unix_timestamp() - self.start_timestamp) * 1000) as i32, ) ... self.prefix.clone() + &hex::encode(buf) // prefix is upper case, suffix is lower case ``` Consequences when the id is decoded as V1: - The decoded time is `2021-01-01 + (milliseconds since the start of the month) seconds`, i.e. it jumps ahead ~2.7 years per day of the month. It only lies in the past during the first ~2 days of each month (before ~03:13 UTC on the 3rd in 2026); after that it is in the future. - From ~20:31 UTC on the 25th of each month the milliseconds overflow `i32`. - The month start is only refreshed after `start of month + 30 days`, so e.g. on March 1-2 the offset is still computed from February 1. - The time and sequence part are lower case while the rest of the id (and all other clients) are upper case. - The sequence starts from 1 instead of 0 as in Java. History: #471 added the generator with this time encoding and a 2-byte sequence (32 hex chars); #566 widened the sequence to 4 bytes, so the id got the V1 length but the time field kept the legacy semantics. The unit test was `#[ignore]`d, so nothing checked the encoding. ### Steps to Reproduce Send a message with the Rust producer on any day after the 3rd of a month and decode the message id as V1. For example, a message sent at 2026-11-05 09:03:40 UTC got the id (MAC/PID anonymized): ``` 0156F7E71C361B21BC168b2de000000132 ``` The time field `168b2de0` = 378220000 = 4 days 09:03:40 in milliseconds since 2026-11-01, but decoded as V1 it is `2021-01-01 + 378220000 s` = **2032-12-26 13:06:40 UTC**. ### What Did You Expect to See? The time field is the seconds since 2021-01-01 UTC, the same as other clients, so the id above would be `0156F7E71C361B21BC0AFDE06C00000132` and decode to 2026-11-05 09:03:40 UTC. The whole id is upper case. ### What Did You See Instead? The id decodes to 2032-12-26 13:06:40 UTC, and the suffix is lower case. ### Additional Context Message ids already generated by older Rust clients cannot be fixed; only new ids are affected by the fix. -- 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]
