Keep Task.current_loop() for Python < 3.7

Python 3.11 introduced the concept of uncancelling a cancelled task.

From https://docs.python.org/3/library/asyncio-task.html#task-cancellation

user code should not generally call uncancel. However, in cases when suppressing asyncio.CancelledError is truly desired, it is necessary to also call uncancel() to completely remove the cancellation state.

async-timeout needs to be updated to run uncancel to be compliant with python 3.11.

An example of this being problematic is using async-timeout and something that uses anyio==3.7.1.
Here is a minimal example using httpx==0.24.1

import asyncio
import async_timeout
import httpx

async def main():
    try:
        async with async_timeout.timeout(1):
            await asyncio.sleep(5)
    except TimeoutError:
        pass

    client = httpx.AsyncClient()
    await client.get("https://www.google.com")

if __name__ == "__main__":
    asyncio.run(main())

This causes an asyncio.exceptions.CancelledError at the point of the await client.get(...) call, raised somewhere in anyio due to the cancelling state of the main task not being removed.

Hi!

It was added some type hints in version 3.0.0. But in python 3.5.1 typing.Type is not available.

from typing import Optional, Type
ImportError: cannot import name 'Type'

This is more of a question than a bug report.

Is nesting of timeout context managers supported? If it is, I would expect to find a test case (maybe I have missed it). In any case, it would be nice for this to be explicitly documented.

in the end i want to run math but end it if it takes longer than x to complete but even this doesn't even stop

           async with timeout(5):
                await run_formula()

and

async def run_formula():
    for i in range(100):
        print(i)
        time.sleep(1)

it should stop at 0, 1, 2, 3, 4 but instead it counts all the way to 100

Currently requirements.txt has a host of packages that are at most needed in release prep or testing the package but not used in the production code. E.g. black, isort or flake8.

The downside of this is that the installation in production is unnecessarily bloated and may even conflict with other packages (which may specify a different version of the same packages). Another side effect is that since black is not out of pre-release, installation requires explicilty enabling pre-release in pip.

Is it possible to remove these from requirements.txt and put them in a separate file, so that any release processing tools that explicitly need them can do a pip install -r newfile and do the work?

Hi 👊

This is my first visit to this fine repo, but it seems you have been working hard to keep all dependencies updated so far.

Once you have closed this issue, I'll create separate pull requests for every update as soon as I find one.

That's it for now!

Happy merging! 🤖

Is there a hard requirement for Python 3.5.3? I am asking because ubuntu xenial ships with python 3.5.1 and therefore cannot install this package. If possible, could we change the requirement to python 3.5 instead?

Also note that distrbutions partially have large backports, so 3.5.1 is probably something like 3.5.1 with a pile of patches and probably similar enough to 3.5.3

Is it possible to add support for calling timeout() with waitable as argument without creating context, or will it decrease performance?
I have a case where I use asyncio.wait_for for limiting only connection time of asyncssh.connect which itself creates connection context, but I don't want to limit commands execution time.

Is shift_by meant to increase delay or replace delay. This raises TimeoutError after the 1st second:

import asyncio

from async_timeout import timeout


async def test():
    async with timeout(10) as cm:
        cm.shift_by(1)  # add another second on waiting
        await asyncio.sleep(5)


if __name__ == '__main__':
    asyncio.run(test())

Right now shift_by shifts to self._loop.time() + delay which replaces previous delay with a delay relative to current, not previously defined, time. Is this the expected behavior?

python 3.8.5
async-timeout 4.0.0a3

my code just as follows
`
import asyncio
import aioping
import logging

async def do_ping(host):
try:
delay = await aioping.ping(host, 0.9) * 1000
logging.info("ping response in {:.2f}ms".format(delay))

except TimeoutError:
    logging("ping timed out")

async def ping_for_ever(host):
while True:
await asyncio.sleep(1)
await do_ping(host)

loop = asyncio.get_event_loop()
loop.run_until_complete(ping_for_ever("x.x.x.x"))
`

timeout=0 will be set to None due https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L22

timeout=0 or any special flag for instant timeout can be useful

As well it makes different behaviour with asyncio.wait_for, cuz it supports timeout=0

https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L22

what about implementing timeout=async_timeout.immediate ? If it makes sense I'll do PR

Seems your current alpha is in a stable state, since tests keep passing on dependency updates. We would like to get aiohttp to cut a new release for us to package, as its tests for 3.6.2 result in many failures due to syntax changes in Python 3.8. aiohttp trunk currently requires 'async_timeout>=4.0a2,<5.0', and it would be great if you could tag a new stable release for downstream to use.

Hi 👊

This is my first visit to this fine repo, but it seems you have been working hard to keep all dependencies updated so far.

Once you have closed this issue, I'll create seperate pull requests for every update as soon as I find one.

That's it for now!

Happy merging! 🤖

Do like this:

REPO_NAME={{ YOUR_REPO_NAME }}
travis encrypt -r "aio-libs/${REPO_NAME}" --api-endpoint 'https://api.travis-ci.com/'

Ref: https://github.com/orgs/aio-libs/teams/admins/discussions/9

1. Context manager should return itself from __enter__.
2. expired property should return True if timeout expired.

The change allows to figure out is asyncio.TimeoutError was raised by context manager itself or internal code, e.g.

try:
    async with timeout(1.0) as cm:
        await fetch()
except asyncio.TimeoutError:
    if cm.expired:
         # top level timeout
    else:
         # `fetch()` raised timeout itself

@hellysmile we discussed the change offline.
Do you agree with proposed API?

A key difference between async-timeout and asyncio.wait_for is that wait_for performs a final test that the task is completed before raising a TimeoutError, whereas async-timeout immediately raises the error when the timeout expires.

This difference is really important when a system is at 100% CPU usage.

Let's say you're making a HTTP request with a timeout of 15 seconds. The request takes 14.5 seconds to complete, but then the system hangs for a full second due to CPU contention.

• async-timeout will report a timeout error, since the timeout will be triggered immediately after the program un-freezes, but before the task completes.
• asyncio.wait_for will not report a timeout error, since it will perform a final check to see if the network request completed before raising the error.

In other words, async-timeout reports timeouts due to CPU and network, whereas wait_for, only reports timeouts due to network.

The result being that, in a system that experiences a brief CPU spike, a great many network requests apear to "time out". The reality is that the python interpreter hung for a second, and the nework is fine.

The affects me when using aiohttp. I've had to wrap the library with a shim that disables all built-in timeouts and wraps network calls with asyncio.wait_for.

Describe the bug

There is a race condition in code that handles connection timeout. If you call cancel on a task that is currently pending in create_connection and connection timeout was already fired then asyncio.CancelledError is not propagated and you get asyncio.TimeoutError instead. The main problem is in how timeouts are handled in async_timeout package. When exitting the context manager after timeout had passed all CancelledError exceptions are swallowed and TimeoutError is raised instead. Unfortunately this is true also if you explicitly cancel the task yourself.

The main problem is that you cannot cancel a task that is using aiohttp because you never know if CancelledError will be raised.

To Reproduce

EDIT: THIS REPRODUCER DOES NOT SHOW THE BEHAVIOUR CORRECTLY - PLEASE REFER TO COMMENTS BELLOW!

import asyncio
from async_timeout import timeout


async def test_task():
    with timeout(1):
        await asyncio.sleep(10)


async def main():
    t = asyncio.create_task(test_task())
    await asyncio.sleep(2)
    t.cancel()
    try:
        await t
    except asyncio.TimeoutError:
        print("Raised TimeoutError")
    except asyncio.CancelledError:
        print("Raised CancelledError")

asyncio.run(main())

Expected behavior

asyncio.CancelledError should never be suppressed when you cancel the task explicitly.

Logs/tracebacks

---

Python Version

Python 3.8.10

aiohttp Version

3.7.4.post0

multidict Version

4.7.6

yarl Version

1.6.0

OS

Linux

Related component

Client

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

It's useful to know how much time is remaining when scheduling tasks that either do not support asyncio's mechanics or provide an independent timeout.
One such example would be running a subprocess with a program that can accept a timeout:

async with timeout(1234) as t:
    p = await asyncio.create_subprocess_exec('iptables', '-w', int(t.remaining), ...)
    await p.wait()

Please add tag 'v1.2.0' and remove '1.2.0'. Our automatic scripts are failing.

Hello. Sorry for maybe stupid question.
Can I do something to prevent timeout error, except using try outside CM?
If no, maybe it is good idea to use some flag, for example silent=True to make such behavior possible?

The latest commits to the repository mention a new release (1.1.1), but there isn't a new release on github.
Was this intentional?
Thanks!

original question

Steps to reproduce

requirements.txt

# Python 3.5.2
aiohttp==2.1.0
async-timeout==1.2.1
chardet==3.0.4
gunicorn==19.7.1
multidict==2.1.6
yarl==0.10.3

1. code in test.py :

import asyncio
import async_timeout
from aiohttp import web

asyncio.set_event_loop(asyncio.new_event_loop())

class A:
    async def am(self):
        with async_timeout.timeout(timeout=1):
            await asyncio.sleep(0.5)

class B:
    a = A()
    async def bm(self):
        await self.a.am()

b = B()

async def hello(request):
    await b.bm()
    return web.Response(text="Hello, world")

app = web.Application()
app.router.add_get('/', hello)

2. run this command gunicorn test:app --worker-class aiohttp.GunicornWebWorker -b 127.0.0.1:8000

3. make request to https://127.0.0.1:8000/ URL.

Get RuntimeError: Timeout context manager should be used inside a task error message.

question

Why in this case async_timeout class have been initialised with developer-defined event loop instead gunicorn-defined (aiohttp.GunicornWebWorker)? How can library provide more informative message to help developer understand why it isn't working?

Here's some code I have:

@memoize
def get_thumbnail_url(url):
    async def get_url(url):
        try:
            return Scraper.for_url(url).scrape()
        except (HTTPError, URLError):
            return None

    async def get_url_with_timeout(url):
        with timeout(30):
            return await get_url(url)
        return None

    return _LOOP.run_until_complete(get_url_with_timeout(url))

I'm wondering if I can avoid having to write run_until_complete by somehow passing _LOOP into timeout. Is that possible?

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

I'm using aiohttp's WebSocket client and want to set my own exception for the current task on message receive timeout. But currently it's impossible due to async-timeout's task cancelling.
Ref: https://github.com/aio-libs/aiohttp/blob/master/aiohttp/client_ws.py#L195

Simple example listing:

import asyncio

from async_timeout import timeout


async def main():
    try:
        async with timeout(1):
            await asyncio.sleep(2)
    except asyncio.TimeoutError:
        future.set_exception(Exception('My exception'))


future = asyncio.ensure_future(main())

loop = asyncio.get_event_loop()
loop.run_forever()

Output:

$ python test_timeout.py
Exception in callback <TaskWakeupMethWrapper object at 0x7f0d9414bbb8>(<Future cancelled>)
handle: <Handle <TaskWakeupMethWrapper object at 0x7f0d9414bbb8>(<Future cancelled>)>
Traceback (most recent call last):
  File "/usr/lib/python3.6/asyncio/events.py", line 145, in _run
    self._callback(*self._args)
asyncio.base_futures.InvalidStateError: invalid state

How can I set my own exception if it possible?

I'm using a package that has async-timeout as a dependency, recently I have started getting an error about a missing package in async-timout:

  ...
  File "/usr/local/lib/python3.7/site-packages/async_timeout/__init__.py", line 8, in <module>
    from typing_extensions import final
ModuleNotFoundError: No module named 'typing_extensions'

Wanted to make you aware. Thanks! :-)

Is there any reason of not using asyncio wait_for https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for ?

What's the motivation of this lib ? any pro ?

Hey, looks like there's a release on github that hasn't been pushed to pypi. Just checking in to see if this is intended or just an oversight.

Hello
there is problem using this library with python 3.9.

$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import async_timeout
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/dist-packages/async_timeout/__init__.py", line 8, in <module>
    from typing_extensions import final
ModuleNotFoundError: No module named 'typing_extensions'

I see that there is already fix for it in your code
https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L9

Could you please release it as soon as possible?

Thank you
& stay safe

Jozef

Information about what internal IO operation was interrupted by timeout expiring is important in some cases, it allows to figure out what exact IO takes too long time.

raise TimeoutError from None should be replaced with raise TimeoutError from exc

How about adding msg argument to task.cancel()?

TL;DR:

def _on_timeout(self, task: "asyncio.Task[None]") -> None:
    task.cancel(msg="timeout")  # <--- add the reason of cancellation
    self._state = _State.TIMEOUT
    # drop the reference early
    self._timeout_handler = None

This would be useful to distinguish the reason of cancellation in library's user programs.

Hi 👊

This is my first visit to this fine repo, but it seems you have been working hard to keep all dependencies updated so far.

Once you have closed this issue, I'll create separate pull requests for every update as soon as I find one.

That's it for now!

Happy merging! 🤖

Now we should use just with timeout(): statement.
It works pretty well but people feedback is a bit confusing: why with instead of async with.

I think it makes sense. Technically timeout support doesn't need async api but it makes learning curve smoother.

i set 1000 seconds
but only the first time it runs well
next round only 10 seconds , it says timeout
what's wrong with my code?

async def _run_debug_mode(self):
    for idx, wallet in enumerate(self.wallets):
        await self._run_timeout(wallet=wallet, delay=(idx + 1)*self.timeout_each_account)
        await self.end_session()


async def _run_timeout(self, wallet=None, delay=None):
    begin_time = datetime.datetime.now()
    try:
        async with async_timeout.timeout(delay) as cm:
            await self._run_one(wallet)
    except:
        await self.end_session()
        end_time = datetime.datetime.now()
        msg = f'运行超时: {wallet.wallet} || 耗时: {end_time-begin_time}'
        self.write_log(msg)