gimmickj opened a new issue, #1195: URL: https://github.com/apache/rocketmq-clients/issues/1195
### Programming Language of the Client Java ### Is Your Feature Request Related to a Problem? # Clarification on `messaging.rocketmq.message.delay_time_level` source in RocketMQ 5 clients Hi maintainers, I’m aligning the C# OpenTelemetry instrumentation with the latest RocketMQ semantic conventions: - https://opentelemetry.io/docs/specs/semconv/messaging/rocketmq/ - https://opentelemetry.io/docs/specs/semconv/registry/attributes/messaging/ I noticed `messaging.rocketmq.message.delay_time_level` is listed, but in RocketMQ 5 client models/protocols we only see `delivery_timestamp` (e.g. `SystemProperties.delivery_timestamp`) and no explicit delay-level field. From Java/Python implementations, I can find support for `delivery_timestamp`, but not a clear source for `delay_time_level`. ## Questions 1. Should clients emit `messaging.rocketmq.message.delay_time_level` at all for RocketMQ 5? 2. If yes, what is the canonical data source or mapping rule? 3. If no source exists, is it acceptable to emit only `messaging.rocketmq.message.delivery_timestamp` and skip `delay_time_level`? If helpful, I can submit a docs PR to clarify this behavior across SDKs. Thanks! ### Describe the Solution You'd Like I’d like an official clarification for RocketMQ 5 client instrumentation: 1. Whether `messaging.rocketmq.message.delay_time_level` should be emitted in RocketMQ 5 clients. 2. If it should be emitted, define the canonical source field and mapping rule. 3. If there is no reliable source, explicitly recommend emitting only `messaging.rocketmq.message.delivery_timestamp`. A short doc update in the RocketMQ semconv/client docs would be enough. ### Describe Alternatives You've Considered I considered these alternatives: 1. Keep current behavior in C# and emit only `messaging.rocketmq.message.delivery_timestamp`. - Pros: based on real protocol field, no fake value. - Cons: `delay_time_level` remains absent. 2. Derive `delay_time_level` heuristically from `delivery_timestamp`. - Pros: can fill the attribute. - Cons: not reliable and may be incorrect. 3. Read a custom user property as delay level. - Pros: technically possible. - Cons: not standardized and inconsistent across SDKs. Given the above, I prefer official guidance before implementing `delay_time_level`. ### Additional Context _No response_ -- 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]
