Skip to content

asyncio.Timeout raises AttributeError when not used in loop #111085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Gobot1234 opened this issue Oct 19, 2023 · 6 comments
Closed

asyncio.Timeout raises AttributeError when not used in loop #111085

Gobot1234 opened this issue Oct 19, 2023 · 6 comments
Labels
3.11 only security fixes 3.12 only security fixes 3.13 bugs and security fixes topic-asyncio type-bug An unexpected behavior, bug, or error

Comments

@Gobot1234
Copy link
Contributor

Gobot1234 commented Oct 19, 2023

Bug report

Bug description:

    async def __aenter__(self) -> "Timeout":
        self._state = _State.ENTERED
        self._task = tasks.current_task()
        self._cancelling = self._task.cancelling()  # AttributeError
        if self._task is None:
            raise RuntimeError("Timeout should be used inside a task")
        self.reschedule(self._when)
        return self

Honestly I don't know how to get this to error but it's possible according to the types

CPython versions tested on:

3.13, CPython main branch

Operating systems tested on:

No response

Linked PRs

@Gobot1234 Gobot1234 added the type-bug An unexpected behavior, bug, or error label Oct 19, 2023
@github-project-automation github-project-automation bot moved this to Todo in asyncio Oct 19, 2023
@Eclips4 Eclips4 added 3.11 only security fixes 3.12 only security fixes 3.13 bugs and security fixes labels Oct 19, 2023
@gvanrossum
Copy link
Member

What is the bug? You just posted some code, I am missing context for that code.

@Gobot1234
Copy link
Contributor Author

It accesses self._task while it could still be None before the is None check

@gvanrossum
Copy link
Member

Got it. Do you want to send a PR?

@Gobot1234
Copy link
Contributor Author

The PR is already sent :)

@gvanrossum
Copy link
Member

Oh wait. You started with the PR. A bit unconventional. :-)

I don’t think I am needed here.

@serhiy-storchaka
Copy link
Member

The problem is larger and more complex than it looked. It applies as well to TaskGroup.

  • The valid state is not always checked.
  • If it is checked, sometimes assert is used for this, even if the condition can be false.
  • If an exception is raised, it can left the object in inconsistent state which breaks checks in the following operations.

It was also not trivial to write tests for this. So I created a new PR #111111.

serhiy-storchaka added a commit that referenced this issue Oct 21, 2023
asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

Co-authored-by: James Hilton-Balfe <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 21, 2023
…ythonGH-111111)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

(cherry picked from commit 6c23635)

Co-authored-by: Serhiy Storchaka <[email protected]>
Co-authored-by: James Hilton-Balfe <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 21, 2023
…ythonGH-111111)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

(cherry picked from commit 6c23635)

Co-authored-by: Serhiy Storchaka <[email protected]>
Co-authored-by: James Hilton-Balfe <[email protected]>
serhiy-storchaka added a commit that referenced this issue Oct 21, 2023
…GH-111111) (GH-111172)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

(cherry picked from commit 6c23635)

Co-authored-by: Serhiy Storchaka <[email protected]>
Co-authored-by: James Hilton-Balfe <[email protected]>
serhiy-storchaka added a commit that referenced this issue Oct 21, 2023
…GH-111111) (GH-111171)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

(cherry picked from commit 6c23635)

Co-authored-by: Serhiy Storchaka <[email protected]>
Co-authored-by: James Hilton-Balfe <[email protected]>
@github-project-automation github-project-automation bot moved this from Todo to Done in asyncio Oct 22, 2023
aisk pushed a commit to aisk/cpython that referenced this issue Feb 11, 2024
…ython#111111)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

Co-authored-by: James Hilton-Balfe <[email protected]>
Glyphack pushed a commit to Glyphack/cpython that referenced this issue Sep 2, 2024
…ython#111111)

asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.

* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
  sequentially).
* If there is no current task when entering the context manager.

They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).

Co-authored-by: James Hilton-Balfe <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.11 only security fixes 3.12 only security fixes 3.13 bugs and security fixes topic-asyncio type-bug An unexpected behavior, bug, or error
Projects
Status: Done
Development

No branches or pull requests

4 participants