[ServiceBus] ExpiresAt is set incorrectly when sending a cloned message

[SeanFeldman]

Description

When cloning a message w/o TTL and sending the new message to ASB w/o specifying TTL, the ExpiresAt should be set to the EnqueuedTime + TimeToLive according to docs.

The UTC instant at which the message is marked for removal and no longer available for retrieval from the entity due to expiration. Expiry is controlled by the TimeToLive property and this property is computed from EnqueuedTime+TimeToLive

But that's not the behaviour for a "cloned" message using Azure.Messaging.ServiceBus 7.16.1+5a3f6c0a6c047e8bfa26cdf29ae2f5771ab08b2b w/o TTL on the message.

Actual Behavior

Messages cloned using

var clone = new ServiceBusMessage(serviceBusReceiveMessage);

and sent w/o TTL to an entity with TTL set to TimeSpan.MaxValue

have their ExpiresAt value set to less than 2 months into the future (49.17:02:47.2950000), unless a workaround is applied (highlighted entries, see below)

Expected Behavior

ExpireAt should be set to 9999-12-31 23:59 for messages w/o TTL on entities with TTL set to TimeSpan.MaxValue and no TTL on the originally received messages.

Workaround

The workaround is to set the TTL on the cloned message to TimeSpan.MaxValue

clone.TimeToLive = TimeSpan.MaxValue;

[SeanFeldman]

I've peeked into the public ServiceBusMessage(ServiceBusReceivedMessage receivedMessage) constructor code to debug what happened. For a message with ID 350db999-2efd-497e-b2fb-f9df81306f31, the TTL reported by the broker was right.

But when the message was received and used to construct a new ServiceBusMessage, the received message TTL was the arbitrary 49.17:02:47.2950000 value.

[SeanFeldman]

Closed in favour of the SDK issue https://github.com/Azure/azure-sdk-for-net/issues/38875