Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
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. |
Backport to 3.10: 💚 backport PR created✅ Backport PR branch: Backported as #8627 🤖 @patchback |
(cherry picked from commit 1fcef94)
Backport to 3.11: 💚 backport PR created✅ Backport PR branch: Backported as #8628 🤖 @patchback |
(cherry picked from commit 1fcef94)
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. |
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.