gh-128479: fix asyncio staggered race leaking tasks, and logging unhandled exception.append exception

[graingert]

Issue currently pending, but this fixes the following exception when running under anyio's pytest plugin, or logging unhandled asyncio exceptions:

https://github.com/Chia-Network/chia-blockchain/actions/runs/12586550910/job/35084132471#step:16:1813

 ______ test_long_reorg_nodes[ConsensusMode.HARD_FORK_2_0-2-500-100-True] _______ [gw1] darwin -- Python 3.12.8 /Users/runner/work/chia-blockchain/chia-blockchain/.venv/bin/python /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/staggered.py:104: in run_one_coro result = await coro_fn() .venv/lib/python3.12/site-packages/aiohappyeyeballs/impl.py:166: in _connect_sock await loop.sock_connect(sock, address) /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/selector_events.py:651: in sock_connect return await fut E asyncio.exceptions.CancelledError During handling of the above exception, another exception occurred: .venv/lib/python3.12/site-packages/anyio/pytest_plugin.py:160: in pytest_pyfunc_call runner.run_test(pyfuncitem.obj, testargs) .venv/lib/python3.12/site-packages/anyio/_backends/_asyncio.py:2316: in run_test self._raise_async_exceptions() .venv/lib/python3.12/site-packages/anyio/_backends/_asyncio.py:2220: in _raise_async_exceptions raise exceptions[0] /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/asyncio/staggered.py:108: in run_one_coro exceptions[this_index] = e E NameError: cannot access free variable 'exceptions' where it is not associated with a value in enclosing scope 

• Issue: asyncio.staggered.staggered_race can log NameError: cannot access free variable 'exceptions' where it is not associated with a value in enclosing scope #128479

[graingert]

probably this should just always raise it, not sure why this was suppressed in the original code

[ZeroIntensity]

I haven't stayed up-to-date with the staggered_race problems. Did we adopt some of aiohttp's tests?

[graingert]

I haven't stayed up-to-date with the staggered_race problems. Did we adopt some of aiohttp's tests?

Did you mean aiohappyeyeballs? No those have yet to be added

[ZeroIntensity]

Ah yeah, aiohappyeyeballs. Can we run their (old) test suite against this PR? I don't want another release blocker fiasco.

[graingert]

@ZeroIntensity I got it running against the newest suite: graingert/aiohappyeyeballs@8587b00#diff-d38ea0c7de1f2c4e6030c2e14c786b426be1f20310d14997973c0c1f7621d0e4L33

but it failed on a test that multiple winners can complete. This is not acceptable for the cpython implementation, because it would result in connection objects being left unclosed and result in ResourceWarnings.

I'm not sure which test suite is the old test suite you refer to, do you have a commit hash for that?

[ZeroIntensity]

I'm not sure which test suite is the old test suite you refer to, do you have a commit hash for that?

I don't have a commit hash, but I mean "old" as in when aiohappyeyeballs was still using our staggered_race instead of their own implementation. But, if you just replaced their staggered_race with ours then I'm comfortable.

[ZeroIntensity]

Sorry for dropping the ball here. Looks mostly good, with a few edge cases/nitpicks to be dealt with.

[miss-islington-app]

Thanks @graingert for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-129227 is a backport of this pull request to the 3.13 branch.

[miss-islington-app]

Sorry @graingert and @ambv, I had trouble completing the backport.
Please retry by removing and re-adding the "needs backport to 3.13" label.
Please backport backport using cherry_picker on the command line.

cherry_picker ec91e1c2762412f1408b0dfb5d281873b852affe 3.13 

[bedevere-app]

GH-129228 is a backport of this pull request to the 3.12 branch.

[ambv]

The misleading comment by miss-islington is actually an improvement over the previous behavior. There were HTTP timeouts in PR creation so Stamina retried them a few times, not getting a response in time. The final retry returned HTTP 422 since one of the previous retries actually managed to create a PR. And this HTTP 422 is the basis of miss-islington's comment about not being able to complete the backport.

This is all due to an ongoing GitHub incident with Actions: