Messaging: which semantics auxiliary operations should follow

[lmolkova]

Messaging libraries have multiple operations unrelated to publishing/consuming or settling.

For example, Azure ServiceBus supports the following operations:

• producer side:
  • send message(s)
  • schedule message
  • cancel scheduled message
• consumer side:
  • peek
  • receive
  • process callback
  • settlement
• aux operations, not strictly related to message flow
  • start/end session
  • renew locks
  • renew tokens
  • configure routing, filtering and other things (more on a control plane side)

Should we have a language in the spec limiting applicability of semconv to a message-related set of defined operations?

Proposal:

If messaging instrumentation wants to cover other operations, they are free to use messaging attributes, but there is no guidance or guarantees there and backends can distinguish message-flow-related operations with messaging.operation attribute value.

[alevenberg]

Discussed today in the WG.

Attached is a sample screenshot, we discussed the link between the receive and lease span will move to become a span between the create to the lease.

[alevenberg]

Updated screenshot