Unexpected timeout behavior

[Dacid99]

Describe the bug

When network connection is lost while being in session on the exchangeserver, the retry_policy isn't applied. Instead a default timeout behavior with non-configurable timeout takes over.

In contrast, if the session is not yet started and there is no network connection, the retry_policy is applied, allowing a user-defined timeout.

If this is not a bug, it is at least unexpected behavior.

To Reproduce

import time

import exchangelib


credentials = exchangelib.Credentials(
    username="<your_address>",, password="<pwd>"
)
retry_policy = exchangelib.FaultTolerance(max_wait=10)
config = exchangelib.Configuration(
    credentials=credentials, retry_policy=retry_policy, server="<server>"
)
acc = exchangelib.Account(
    primary_smtp_address="<your_address>",
    config=config,
)

acc.msg_folder_root.refresh()

print("disconnect network now")
time.sleep(10)

start = time.time()
try:
    acc.msg_folder_root.refresh()
except exchangelib.errors.ErrorTimeoutExpired as e:
    print(time.time() - start)
    # timeout is now 120s
    print(e)

Expected behavior
I would expect the retry_policy and its user-defined max_wait to be applied. Currently a connection loss while being in session blocks the thread for 120s.

Additional context
Python3.14.2
exchangelib 5.6.0

[ecederstrand]

Thanks for the report! Protocol.TIMEOUT is the default timeout for a single HTTP request. FaultTolerance.max_wait is a higher-level timeout intended to trigger when HTTP requests have accumulated timeouts up to this limit.

The code does indeed not take into account that FaultTolerance.max_wait could be set lower than Protocol.TIMEOUT. This is a bug.

[ecederstrand]

A workaround for now could be to do this:

from exchangelib.protocol import Protocol
Protocol.TIMEOUT = 20

# The rest of your script goes here

[Dacid99]

Thank you for the quick response and the workaround! I think this will work for me.