10 mins idle timeout (no activity on a link) would make the service proactively shutdown a link. This seems to be a common scenario where we should not expect there's always messaging activity happening.

In current condition based error handling, LinkDetach (triggered by the 10mins idle timeout) would fall into the category of ServiceBusError.
However, to recovery from the error is pretty straight forward by re-establishing the link.
We could do this internally to simplify user code.

• need cross team check

Error logging

Traceback (most recent call last):#12
File "/usr/local/lib/python3.9/site-packages/azure/servicebus/_base_handler.py", line 293, in _do_retryable_operation#012
return operation(**kwargs)#12
File "/usr/local/lib/python3.9/site-packages/azure/servicebus/_servicebus_sender.py", line 238, in _send#012
self._handler.send_message(message.message)#12
File "/usr/local/lib/python3.9/site-packages/uamqp/client.py", line 725, in send_message#012
running = self.do_work()#12
File "/usr/local/lib/python3.9/site-packages/uamqp/client.py", line 395, in do_work#012
if not self.client_ready():#12
File "/usr/local/lib/python3.9/site-packages/uamqp/client.py", line 379, in client_ready#012
if not self._client_ready():#12
File "/usr/local/lib/python3.9/site-packages/uamqp/client.py", line 527, in _client_ready#012
if self.message_handler.get_state() == constants.MessageSenderState.Error:#12
File "/usr/local/lib/python3.9/site-packages/uamqp/sender.py", line 184, in get_state#012
raise self._error#012uamqp.errors.LinkDetach: ErrorCodes.LinkDetachForced: The link 'G6:3354839:sender-link-4e63dd77-7eaf-4d6d-8448-299b5161661b' is force detached. Code: publisher(link11766). Details: AmqpMessagePublisher.IdleTimerExpired: Idle timeout: 00:10:00.#12#012