Fix handler waiting on shutdown

[Dreamsorcerer]

There seems to be some kind of race condition in certain circumstance which can lead to .wait_for_disconnection() being called after the request has already been cancelled.

Additionally, I see no guarantee that when .wait_for_disconnection() completes, that the handler itself has completed (and not suppressed a cancellation etc.).

However, I couldn't figure out a shutdown test in test_run_app.py that triggers this edge case.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.68%. Comparing base (b7121e5) to head (99b0c5a).
Report is 861 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8611      +/-   ##
==========================================
- Coverage   97.70%   97.68%   -0.03%     
==========================================
  Files         107      107              
  Lines       33438    33441       +3     
  Branches     3927     3928       +1     
==========================================
- Hits        32672    32666       -6     
- Misses        555      563       +8     
- Partials      211      212       +1     

Flag	Coverage Δ
CI-GHA	97.59% <100.00%> (-0.03%)	⬇️
OS-Linux	97.24% <100.00%> (-0.03%)	⬇️
OS-Windows	95.61% <100.00%> (-0.03%)	⬇️
OS-macOS	96.91% <100.00%> (-0.03%)	⬇️
Py-3.10.11	97.06% <100.00%> (-0.03%)	⬇️
Py-3.10.14	96.99% <100.00%> (-0.03%)	⬇️
Py-3.11.9	97.22% <100.00%> (-0.03%)	⬇️
Py-3.12.4	97.35% <100.00%> (-0.03%)	⬇️
Py-3.8.10	95.37% <100.00%> (-0.03%)	⬇️
Py-3.8.18	96.89% <100.00%> (-0.03%)	⬇️
Py-3.9.13	97.04% <100.00%> (-0.03%)	⬇️
Py-3.9.19	96.99% <100.00%> (-0.03%)	⬇️
Py-pypy7.3.16	96.56% <100.00%> (-0.03%)	⬇️
VM-macos	96.91% <100.00%> (-0.03%)	⬇️
VM-ubuntu	97.24% <100.00%> (-0.03%)	⬇️
VM-windows	95.61% <100.00%> (-0.03%)	⬇️

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.

[Dreamsorcerer]

So, I'm now not convinced that wait_for_disconnection() is useful (and possibly not correct). Maybe it should be removed again...?

[bdraco]

So, I'm now not convinced that wait_for_disconnection() is useful (and possibly not correct). Maybe it should be removed again...?

I'm not sure its useful, but I've also never had a use case for it. I'd open an issue to provide notice of intent to remove it, and than do so in 30 days if nobody objects.

[patchback]

Backport to 3.10: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.10/1fcef940e37c93f1dc05b859816affaf7228b2f8/pr-8611

Backported as #8627

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

[patchback]

Backport to 3.11: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.11/1fcef940e37c93f1dc05b859816affaf7228b2f8/pr-8611

Backported as #8628

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

[Dreamsorcerer]

I'm not sure its useful, but I've also never had a use case for it. I'd open an issue to provide notice of intent to remove it, and than do so in 30 days if nobody objects.

Well, it's only been in a release for a week or so. So, it's incredibly unlikely people are already using it, we can probably just strip in the next 3.10 release before most users have finished upgrading to 3.10.

[bdraco]

I'm not sure its useful, but I've also never had a use case for it. I'd open an issue to provide notice of intent to remove it, and than do so in 30 days if nobody objects.

Well, it's only been in a release for a week or so. So, it's incredibly unlikely people are already using it, we can probably just strip in the next 3.10 release before most users have finished upgrading to 3.10.

I agree. No need to wait as its unlikely its being used.