IndexError when calling asyncio.open_connection

[vToMy]

Bug report

Bug description:

I unfortunately don't have a minimal reproducible example, as it happens in a complex system under high concurrent load, but I get the following error after calling: await asyncio.open_connection(host, port)

File "/usr/local/lib/python3.13/asyncio/base_events.py", line 1169, in create_connection
  model = str(exceptions[0])
                 ~~~~~~~^^^
IndexError: list index out of range

Whatever the issue is, this is not proper error handling on python's part.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-135836: Fix IndexError in asyncio.create_connection with empty exceptions list #135845
• gh-135836: take into account staggered exceptions #135874
• gh-135836: Fix IndexError in asyncio.create_connection() #135875
• [3.14] gh-135836: Fix IndexError in asyncio.create_connection with empty exceptions list (GH-135845) #136167
• [3.13] gh-135836: Fix IndexError in asyncio.create_connection with empty exceptions list (GH-135845) #136168
• [3.14] gh-135836: Fix IndexError in asyncio.create_connection() (GH-135875) #136221
• [3.13] gh-135836: Fix IndexError in asyncio.create_connection() (GH-135875) #136222

[LamentXU123]

It seems like the exception list is empty. Could you add a breakpoint() in your complex system to see why? Some debugging information will be great caz we can't address the bug if we don't know what is going on in your system. the code that triggers the bug will be great.

[heliang666s]

Hi @LamentXU123 ,

Found the root cause! The empty exceptions list occurs in Happy Eyeballs algorithm:

Location: base_events.py:1169 in create_connection()

Issue: When staggered_race() cancels slow connections, empty sublists remain in exceptions list. After flattening: [[], []] → [], then str(exceptions[0]) → IndexError.

Fix:

# Before (buggy):
else:
    model = str(exceptions[0])  # IndexError on empty list

# After (fixed):  
elif len(exceptions) > 1:
    model = str(exceptions[0])  # Safe
else:
    raise OSError('create_connection failed')  # Handle empty list

Debug: Add print(f"exceptions={exceptions}") before line 1169 to see empty list.

This happens with happy_eyeballs_delay parameter under concurrent load.

I'm happy to submit a PR with the fix if you'd like. The change is minimal and maintains backward compatibility while preventing the IndexError crash in production environments.

Best regards,

[LamentXU123]

Thanks! Raising a exception is proper there I think, but could we prevent the bug? (something like avoiding an empty list of exceptions) If yes that will be better tho. But if not I think correcting the exception is necessary.

I am not the maintianer tho. cc @serhiy-storchaka

[vToMy]

I don't think the proposed PR is the proper way to solve it.
I am not using happy_eyeballs_delay when I create the connection, and the default is None.

It seems OSError is swallowed when not using happy eyeballs, evident by:

# not using happy eyeballs
for addrinfo in infos:
    try:
        sock = await self._connect_sock(
            exceptions, addrinfo, laddr_infos)
        break
    except OSError:
        continue

This should somehow be properly handled in the above for-loop, or in _connect_sock (or both).

[LamentXU123]

I don't think the proposed PR is the proper way to solve it. I am not using happy_eyeballs_delay when I create the connection, and the default is None.

In the PR they actually change it to TimeoutError, nvm

[serhiy-storchaka]

If _connect_sock() raises an OSError, it should also add it to exceptions. The only potential problem is if sock.close() fails -- that exception will not be added to the list. Can it be the cause of that case?

[vToMy]

I think this is the problematic part:

else:  # all bind attempts failed
    if my_exceptions:
        raise my_exceptions.pop()
    else:
        raise OSError(f"no matching local address with {family=} found")

If my_exceptions is empty - the OSError raised is then swallowed in the loop (see my previous comment).
If it has 1 item, that item is also swallowed since pop is called.
If it has more than 1 item, the first item is discarded which is also not ideal.