Workaround uvloop losing track of sockets when passing a socket to create_connection#11539
Workaround uvloop losing track of sockets when passing a socket to create_connection#11539
Conversation
|
This still needs tests |
❌ 1 Tests Failed:
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
CodSpeed Performance ReportMerging #11539 will not alter performanceComparing Summary
|
|
This causes widespread localhost service access failures, aiohappyeyeballs defaults to IPv6-first resolution, but most localhost services only listen on IPv4. |
Are you saying it causes failures when happyeyeballs is enabled? I would expect the behavior to be the same when its disabled |
only cause when happyeyeballs is disabled. weather happyeyeballs is enabled or disabled. resolved addrinfo always comes from happyeyeballs and IPV6 first. first_addr_infos = addr_infos[0]
address_tuple = first_addr_infos[4]
host: str = address_tuple[0]
port: int = address_tuple[1]when IPv6 is enabled, |
I'm lost on this comment as happyeyeballs doesn't do the resolution, the configured resolver does |
my mistake,it's os related. but always only get first address when happyeyeballs disabled will broken localhost ipv4 service under some os as ubuntu. |
|
It will eventually fallback to the next address if the timeout is long enough, which is the pre-happyeyeballs behavior. In Home Assistant we used to set the family to AF_INET before we had happyeyeballs to disable IPv6 |
|
is winloop is also affected by this or is it just uvloop? |
|
Any update? Maybe I prefer to do a monkey patch, if it will cost much more time to merge this fix. |
What do these changes do?
Workaround uvloop losing track of sockets when passing a socket to
create_connection.As we are coming up on a year of MagicStack/uvloop#645, and the attempt to fix it MagicStack/uvloop#646 being open, it appears the issue is not going to be fixed in uvloop soon.
related issue #10506 where this solution has been tested
Are there changes in behavior for the user?
Is it a substantial burden for the maintainers to support this?
Related issue number
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.