search

aio-libs / aiohappyeyeballs

Happy Eyeballs for pre-resolved hosts
Other
8 stars 8 forks source link

AssertionError only with version 2.4.2 #100

Open dmoklaf opened 4 hours ago

dmoklaf commented 4 hours ago

Describe the bug Running the most recent versions of aiohappyeyeballs (2.4.2) with aiohttp triggers an AssertionError within aiohappyeyeballs:

Traceback (most recent call last):
  File "/opt/homebrew/Caskroom/miniforge/base/envs/work/lib/python3.12/site-packages/aiohappyeyeballs/_staggered.py", line 85, in run_one_coro
    assert winner_index is None  # noqa: S101
           ^^^^^^^^^^^^^^^^^^^^
AssertionError

Running the exact same code with aiohappyeyeballs 2.4.1 or 2.4.0 triggers no such bug.

To Reproduce No clear steps, as this is generated by a crawler with a lot of URIs. Could try to extract a simple case if this is necessary.

Additional context Python artifacts:

Installed through miniforge:

OS:

webknjaz commented 3 hours ago

Bisecting would be useful, if course. It sounds it might be necessary to use a fuzzer to reproduce. I wonder if writing hypothesis tests could reveal some corner cases...

dmoklaf commented 3 hours ago

I did bisect, and it's definitely 2.4.2 - the new classes added there are causing this.

bdraco commented 3 hours ago

It would be great if you could come up with a minimum reproducer. This code is copied from cpython main so we will need to let them know as well.

webknjaz commented 2 hours ago

Within 2.4.2, do we have a specific commit causing this?

webknjaz commented 1 hour ago

Also, is this serious enough to yank the version from PyPI?

dmoklaf commented 1 hour ago

As far as I am concerned, I had to rollback to 2.4.1. I just can't use 2.4.2, it crashes immediately, again and again. Unfortunately, I can't today dig into this (extracting a reproducible case) but clearly 2.4.2 is not functional, at least for aiohttp client use cases similar to mine (crawling a few websites, only a few hundred pages per day). Note: I make a very standard use of aiohttp or python asyncio library and runtime. No hack, no side threads, no calls to undocumented APIs, nothing out of what is stated in the aiohttp documentation. This code has been very stable over the last 2 years.

dmoklaf commented 1 hour ago

Within 2.4.2, do we have a specific commit causing this?

2.4.2 is made of 2 commits: https://github.com/aio-libs/aiohappyeyeballs/compare/v2.4.1...v2.4.2

The second one (https://github.com/aio-libs/aiohappyeyeballs/commit/04dbbe5be7c38bdbf8ec9e31491fe4d052d15908) is dedicated only to updating the version numbers from 2.4.1 to 2.4.2. So it is the first commit (#95) which is responsible for the bug

dmoklaf commented 1 hour ago

I made a big mistake (sorry for that I relied on the conda installer and did not see it did not have 2.4.1 available) - I thought I had tested 2.4.1 successfully but my package installer (conda forge) had installed 2.4.0.

After re-running everything, it is indeed 2.4.1 which is faulty. It has several commits so I don't know yet which one is wrong (I will have to bisect)