Detailed TimeoutError message not captured when handling asyncio.TimeoutError in aiohttp about aiohttp HOT 8 OPEN

The request is for an error message to be added to the exception. However, in many places we use asyncio.timeout(), which doesn't support any parameters. It's not commonplace to include messages in TimeoutError, and given that we might want to replace the other instances with asyncio.timeout() later, I'd suggest we don't commit to this feature.

from aiohttp.

My understanding of this response is that you propose enhancing asyncio.Timeout by adding an exception_cls parameter and possibly **kwargs in its __init__() method.

That's probably more flexible that my initial thought, which was just to have a msg parameter that's passed to TimeoutError.

from aiohttp.

Perhaps #8089 will help a bit.

from aiohttp.

Perhaps #8089 will help a bit.

I haven't read PR content carefully, but it doesn't seem to have been modified here

from aiohttp.

The request is for an error message to be added to the exception. However, in many places we use asyncio.timeout(), which doesn't support any parameters. It's not commonplace to include messages in TimeoutError, and given that we might want to replace the other instances with asyncio.timeout() later, I'd suggest we don't commit to this feature.

Appreciate your response to this issue. However, I would like to emphasize the importance of providing error types and details in timeout exceptions, and offer a more accurate comparison based on how requests and httpx handle timeouts.

Current Scenario:

aiohttp Example: Currently, when a timeout occurs in aiohttp, it raises a generic asyncio.TimeoutError without specifying the type of timeout or providing detailed information.

async with aiohttp.ClientSession() as client:
    res = await client.get('https://postman-echo.com/delay/3', timeout=1)

Traceback (most recent call last):
  ...
TimeoutError: (No detailed message provided)

requests Example (Connection Timeout): The requests library does indeed provide a specific exception type ConnectTimeout along with detailed error information:

res = requests.get('https://postman-echo.com/delay/3', timeout=0.1)

Traceback (most recent call last):
  ...
requests.exceptions.ConnectTimeout: HTTPSConnectionPool(host='postman-echo.com', port=443): Max retries exceeded with url: /delay/3 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x107fe8d90>, 'Connection to postman-echo.com timed out. (connect timeout=0.1)'))

requests Example (Read Timeout): Similarly, for read timeouts, requests provides a distinct exception type ReadTimeout accompanied by a descriptive message:

res = requests.get('https://postman-echo.com/delay/3', timeout=1)

Traceback (most recent call last):
  ...
requests.exceptions.ConnectTimeout: HTTPSConnectionPool(host='postman-echo.com', port=443): Max retries exceeded with url: /delay/3 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x107fe8d90>, 'Connection to postman-echo.com timed out. (connect timeout=0.1)'))

httpx Example (Connection & Read Timeouts): While httpx offers separate exception types ConnectTimeout and ReadTimeout, it doesn't include as much detailed network context information directly as requests:

async with httpx.AsyncClient(verify=False) as client:
    res = await client.get('https://postman-echo.com/delay/3', timeout=.1)

Traceback (most recent call last):
  ...
httpx.ConnectTimeout

async with httpx.AsyncClient(verify=False) as client:
    res = await client.get('https://postman-echo.com/delay/3', timeout=1)

Traceback (most recent call last):
  ...
httpx.ReadTimeout

Considering aiohttp's future plans to utilize asyncio.timeout(), i suggest considering ways to refine aiohttp's timeout exceptions into different types of timeouts with corresponding context details. This would enable developers to quickly identify the root cause of problems, rather than just encountering a general TimeoutError. Such an improvement would maintain compatibility with asyncio while significantly enhancing users' ability to troubleshoot and resolve timeout-related issues efficiently.

Look forward to further discussing.

from aiohttp.

However, I would like to emphasize the importance of providing error types and details in timeout exceptions

Then maybe also make a proposal to cpython? If they add a message argument or similar to asyncio.timeout(), then we can use that. Otherwise, we'd have to add a bunch of reraises in, which seems a little awkward to me:

try:
    with asyncio.timeout(...):
        ...
except TimeoutError:
    raise TimeoutError("...")

from aiohttp.

My understanding of this response is that you propose enhancing asyncio.Timeout by adding an exception_cls parameter and possibly **kwargs in its __init__() method. This would allow asyncio.timeout() to raise a custom exception such as exception_cls(**kwargs) instead of the default TimeoutError.

# Hypothetical usage after an update to asyncio.timeout()
class CustomTimeoutError(Exception):
    def __init__(self, message, **kwargs):
        self.url = url
        super().__init__(message)

try:
    with asyncio.timeout(5.0, exception_cls=CustomTimeoutError, url="https://example.com"):
        # Perform asynchronous operations
        ...
except CustomTimeoutError as e:
    print(f"Timed out while accessing {e.url}: {e}")

I wholeheartedly agree that implementing such a feature would be beneficial. It would significantly improve developers' ability to understand and troubleshoot timeout issues by providing contextually rich error messages.

Meanwhile, I acknowledge your concern about having to introduce awkward re-raising logic within aiohttp if this feature is not available. However, even without the direct support from asyncio, aiohttp could still internally handle and convert these exceptions by catching asyncio.TimeoutError instances and re-raising them as aiohttp-specific subclasses enriched with specific error causes and details.

from aiohttp.

I think, we should consider implementing the suggested context augmentation where possible, if the contributor is willing to present a PoC PR. I'm sure it's useful.

That https://github.com/aio-libs/aiohttp/blob/cdd5c6802e669c93f0077448430349b6dadd8580/aiohttp/helpers.py#L720C45-L720C49 place is an example where we force a from None, while the context is readily available in the local variable exc_val.

from aiohttp.