We have custom logic for absolute_expiry_time for ServiceBusMessage

...we should do the same for AmqpAnnotatedMessage? (.NET has the same logic too!)

@JoshLove-msft

Pinging @yunhaoling @hemanttanwar to make sure the same logic is present in Java/Python too.

we don't have this in python, for service bus message (and annotated message), we don't calculate absolute_expiry_time based on ttl.

two questions:

1. during which process is your logic applied, setting the time_to_live property of a service bus message?
2. absolute_expiry_time is in the amqp message property while ttl is in the amqp message header, I read the amqp spec but didn't find the spec saying those two are related to each other, so do you know why you have this logic?

ttl, Duration in milliseconds for which the message is to be considered "live". If this is set then a message expiration time will be computed based on the time of arrival at an intermediary. Messages that live longer than their expiration time will be discarded (or dead lettered). When a message is transmitted by an intermediary that was received with a ttl, the transmitted message's header SHOULD contain a ttl that is computed as the difference between the current time and the formerly computed message expiration time, i.e., the reduced ttl, so that messages will eventually die if they end up in a delivery loop.
absolute-expiry-time, An absolute time when this message is considered to be expired.

during which process is your logic applied, setting the time_to_live property of a service bus message?

This gets applied to every message that is being sent(during the translation of SBMessage to the internal AMQP message).

absolute_expiry_time is in the amqp message property while ttl is in the amqp message header, I read the amqp spec but didn't find the spec saying those two are related to each other, so do you know why you have this logic?

Not from the spec, service-bus service has a bug that required us to add this(/cc @JoshLove-msft). Clemens is also involved here, it's better to reach out to him and get approval if we're changing anything here.

For JS especially,

• SBMessage
  • doesn't expose the absolute_expiry_time on the message to be sent(and we use the custom logic to set the absolute_expiry_time property while translating it to the internal amqp message)
• AmqpAnnotatedMessage
  • While sending, if we apply the same logic, we're overriding the property set by the user
  • Maybe we can consider removing CreationTime/AbsoluteExpiry from the AmqpAnnotatedMessage that is used for sending and go ahead with the custom logic of calculating it from ttl.

Remove deliveryCount from the AmqpAnnotatedMessage for send side?

Hm....this is an interesting problem we don't have with ServiceBusMessage, now that I think about it, since we make a distinction between a sendable message and a received message.

For now I'd say it's fine. A received AmqpAnnotatedMessage should also be immediately sendable so it should work, and we can just do a quick check to make sure that we aren't in some way dependent on those fields.

@JoshLove-msft @yunhaoling @hemanttanwar what are you guys doing here?

Remove deliveryAnnotations from the AmqpAnnotatedMessage for send side?

Hm....this is an interesting problem we don't have with ServiceBusMessage, now that I think about it, since we make a distinction between a sendable message and a received message.

For now I'd say it's fine. A received AmqpAnnotatedMessage should also be immediately sendable so it should work, and we can just do a quick check to make sure that we aren't in some way dependent on those fields.