Skip to content
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

Do fire DNS tracing events #2858

Merged
merged 2 commits into from
Mar 20, 2018
Merged

Do fire DNS tracing events #2858

merged 2 commits into from
Mar 20, 2018

Conversation

asvetlov
Copy link
Member

Fix for #2841

@asvetlov asvetlov added this to the 3.1 milestone Mar 20, 2018
@asvetlov asvetlov requested a review from pfreixes March 20, 2018 12:56
@codecov-io
Copy link

codecov-io commented Mar 20, 2018

Codecov Report

Merging #2858 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #2858   +/-   ##
=======================================
  Coverage   97.97%   97.97%           
=======================================
  Files          39       39           
  Lines        7444     7444           
  Branches     1307     1307           
=======================================
  Hits         7293     7293           
  Misses         48       48           
  Partials      103      103
Impacted Files Coverage Δ
aiohttp/connector.py 96.82% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f8ea94...7117c2d. Read the comment docs.


await client.get('/redirector', data="foo")
await client.get('http://example.com/redirector', data="foo")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a f"localhost:{server.port}/redirector" does not fire a DNS event? If it does we wouldn't need it the FakeResolver

Copy link
Member Author

@asvetlov asvetlov Mar 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolver doesn't perform DNS lookup for IP addresses, only for domain names.
localhost should be sufficient but unfortunately there are too many boxes with declared but actually disabled IPv6 support.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry I don't get the following sentence.

there are too many boxes with declared but actually disabled IPv6 support.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont want to block the PR just for a test that in any case can be at any moment refactorized.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll try to describe. Some broken environments (Travis-CI included IIRC) resolves localhost to both 127.0.0.1 and ::1 but IPv6 stack is disabled.
By this communication over IPv6 ::1 fails.
That's why aiohttp.test_utils and aiohttp test suite use IPv4 127.0.0.1 explicitly.
The situation could be improved I hope but working on it is definitely out if the issue scope.

@asvetlov asvetlov merged commit 48170b8 into master Mar 20, 2018
@asvetlov asvetlov deleted the fix-dns-tracing-signals branch March 20, 2018 23:07
@lock
Copy link

lock bot commented Oct 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new

@lock lock bot added the outdated label Oct 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 28, 2019
@psf-chronographer psf-chronographer bot added the bot:chronographer:provided There is a change note present in this PR label Oct 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bot:chronographer:provided There is a change note present in this PR bug client outdated
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants