Fixed bug that lead to infinite wait for dns futures

[Logioniz]

What do these changes do?

Fixed bug that lead to infinite wait for dns futures when exception occured in trace.send_dns_cache_miss call.

Are there changes in behavior for the user?

No

Is it a substantial burden for the maintainers to support this?

No

Related issue number

No issue.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder
  • name 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 an
      improper 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 breaking
      changes 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 build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and 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 above
      categories.
  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

[codspeed-hq]

CodSpeed Performance Report

Merging #10529 will not alter performance

_{Comparing Logioniz:master (21f6af2) with master (55c5f1f)}

Summary

✅ 47 untouched benchmarks

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.69%. Comparing base (6d205da) to head (21f6af2).
Report is 8 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10529      +/-   ##
==========================================
- Coverage   98.70%   98.69%   -0.01%     
==========================================
  Files         122      122              
  Lines       37230    37268      +38     
  Branches     2064     2065       +1     
==========================================
+ Hits        36748    36783      +35     
- Misses        335      338       +3     
  Partials      147      147              

Flag	Coverage Δ
CI-GHA	98.58% <100.00%> (-0.01%)	⬇️
OS-Linux	98.24% <100.00%> (-0.01%)	⬇️
OS-Windows	96.18% <100.00%> (-0.01%)	⬇️
OS-macOS	97.36% <100.00%> (+<0.01%)	⬆️
Py-3.10.11	97.27% <100.00%> (-0.01%)	⬇️
Py-3.10.16	97.81% <100.00%> (+<0.01%)	⬆️
Py-3.11.11	97.89% <100.00%> (-0.01%)	⬇️
Py-3.11.9	97.35% <100.00%> (+<0.01%)	⬆️
Py-3.12.8	?
Py-3.12.9	98.35% <100.00%> (+<0.01%)	⬆️
Py-3.13.1	?
Py-3.13.2	98.34% <100.00%> (+<0.01%)	⬆️
Py-3.9.13	97.15% <100.00%> (+<0.01%)	⬆️
Py-3.9.21	97.68% <100.00%> (+<0.01%)	⬆️
Py-pypy7.3.16	86.69% <100.00%> (-4.92%)	⬇️
VM-macos	97.36% <100.00%> (+<0.01%)	⬆️
VM-ubuntu	98.24% <100.00%> (-0.01%)	⬇️
VM-windows	96.18% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Logioniz]

I'm not sure, but it looks like the same problem (endless waiting for dns queries) could occur if an exception is thrown in this part of the code:

aiohttp/aiohttp/connector.py

Lines 985 to 995 in 6d205da

	coro = self._resolve_host_with_throttle(key, host, port, futures, traces)
	loop = asyncio.get_running_loop()
	if sys.version_info >= (3, 12):
	# Optimization for Python 3.12, try to send immediately
	resolved_host_task = asyncio.Task(coro, loop=loop, eager_start=True)
	else:
	resolved_host_task = loop.create_task(coro)
	if not resolved_host_task.done():
	self._resolve_host_tasks.add(resolved_host_task)
	resolved_host_task.add_done_callback(self._resolve_host_tasks.discard)

I want to say that asyncio.get_running_loop, asyncio.Task, loop.create_task, asyncio.shield may throw an exception that leads to the same behavior. What do you think?

[bdraco]

I'm not sure, but it looks like the same problem (endless waiting for dns queries) could occur if an exception is thrown in this part of the code:

aiohttp/aiohttp/connector.py

Lines 985 to 995 in 6d205da

	coro = self._resolve_host_with_throttle(key, host, port, futures, traces)
	loop = asyncio.get_running_loop()
	if sys.version_info >= (3, 12):
	# Optimization for Python 3.12, try to send immediately
	resolved_host_task = asyncio.Task(coro, loop=loop, eager_start=True)
	else:
	resolved_host_task = loop.create_task(coro)
	if not resolved_host_task.done():
	self._resolve_host_tasks.add(resolved_host_task)
	resolved_host_task.add_done_callback(self._resolve_host_tasks.discard)

I want to say that asyncio.get_running_loop, asyncio.Task, loop.create_task, asyncio.shield may throw an exception that leads to the same behavior. What do you think?

I think the only one that would be worth worrying about is awaiting resolved_host_task. If the others are throwing an exception, the system is already likely in an unrecoverable state.

[Logioniz]

Do I need to do something else in this PR?

[bdraco]

Do I need to do something else in this PR?

Did you intend to push another commit for resolved_host_task? Its probably very unlikely to happen but I wasn't sure if you were going to add to this PR or not

[Logioniz]

Hmm, i think that i have already fixed resolved_host_task. Looks like i incorrectly understand you. I will try to add changes if you explain what exactly can go wrong with resolved_host_task.

I think that code in finally block clear _throttle_dns_futures dict.

But btw may be exists another situation where new coroutineawait asyncio.shield(resolved_host_task) will not have time to start executing and it will be canceled by another coroutine. So, looks like need to clear _throttle_dns_futures in except CancelledError block. Have you written about this situation?

[Logioniz]

It looks like my assumption above is incorrect, since asyncio.shield protects against this situation. So, i don't know any bad situations with resolved_host_task.

[bdraco]

It looks like my assumption above is incorrect, since asyncio.shield protects against this situation. So, i don't know any bad situations with resolved_host_task.

I think its very unlikely to be a problem. If we can always address it in a future PR if it is.

I think this PR is fine to merge as-is sans the minor nit I mentioned above

[patchback]

Backport to 3.11: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.11/492f63dc252e76ce892e459081286fb46bde87cf/pr-10529

Backported as #10559

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 3.12: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.12/492f63dc252e76ce892e459081286fb46bde87cf/pr-10529

Backported as #10560

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.