[Feature] Clarification on messaging.rocketmq.message.delay_time_level source in RocketMQ 5 clients

[gimmickj]

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