JoshLove-msft
JoshLove-msft
> @JoshLove-msft it seems 7.8.1 caused a regression. Behavior is happening in both [7.8.1](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.Messaging.ServiceBus_7.8.1) and [7.9.0](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.Messaging.ServiceBus_7.9.0). But you cannot reproduce in 7.8.0?
I have not been able to repro the issue on 7.9.0 using your code. Here are the relevant logs. The send link closes due to the idle timeout as expected,...
Renewing a message with a different receiver is supported. Keeping the receive link alive past the 10 minute idle time enforced by the service will not happen if you are...
Renewing a lock with a different receiver is supported for an unlimited amount of time. You can keep renewing the lock as long as you want and the message will...
Reopening until we document the behavior of the 10 minute server idle timeout resulting in link close and the fact that renewing a message lock keeps the receive link open.
> Do we know who all use it today? It would be good to add those SDKs in the bug and add appropriate labels. > > Also, curious - what...
> Also, curious - what are weak ETag references? My understanding is that weak ETags are used to represent semantic equivalence rather than byte for byte equality. https://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation
> @JoshLove-msft I'd be interested in taking this up. Thanks @levimatheri! Please let me know if you have any questions!
I think that should also be updated, but it doesn't need to be addressed as part of this issue. @AlexanderSher do you know where the code that generates the above...
Closing as this has been added to the troubleshooting guide - https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/Azure.Messaging.ServiceBus/TROUBLESHOOTING.md#operations-in-a-transaction-are-not-retried