-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Stream unpauses protocol before releasing connection #10171
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #10171 +/- ##
=======================================
Coverage 98.75% 98.75%
=======================================
Files 122 122
Lines 36976 36995 +19
Branches 4412 4413 +1
=======================================
+ Hits 36517 36536 +19
Misses 313 313
Partials 146 146
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #10171 will not alter performanceComparing Summary
|
I'm wondering if doing it in BaseConnector._release() may be the safest option, to ensure that it is always unpaused regardless of what any other components might do. Anybody else have any thoughts on it? |
Please give me some time for the review. |
I think it makes sense to have this, at least, in the StreamReader, in the sense of having it clean up after itself. However, I think that having a global catch-all at connection release is also a good idea, just in case we missed some other case that can end up in the same situation. I only did this change because I'm not sure of the consequences of doing this at a more general point might have (looks like it should be ok, but I'm just a newcomer here). |
Yeah, I just figure that if we're releasing a connection, then it has no business being paused. Anything that was trying to read from it has already finished, we're now moving onto parsing a whole new HTTP message. |
I'm assuming this happens on the last chunk of data for the payload which it just enough to go over the high water mark, and than the parser is complete and calls This solution makes sense to me. We should probably do a release sooner rather than later to get this fix out there since its this type of reliability issue is so hard to track down, and its very likely to be happening in other real world use cases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, let's merge and publish a bugfix release
If I don't run out of time, I'll do a release later today (utc-10) |
Backport to 3.11: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply 5185f93 on top of patchback/backports/3.11/5185f932407947fbbabd31c5dc6d72abc5c54171/pr-10171 Backporting merged PR #10171 into master
🤖 @patchback |
Backport to 3.12: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply 5185f93 on top of patchback/backports/3.12/5185f932407947fbbabd31c5dc6d72abc5c54171/pr-10171 Backporting merged PR #10171 into master
🤖 @patchback |
(cherry picked from commit 5185f93)
3.11 backport #10179 |
(cherry picked from commit 5185f93)
3.12 backport #10180 |
…leasing connection (#10179) Co-authored-by: Javier Torres <javier@javiertorres.eu>
…leasing connection (#10180) Co-authored-by: Javier Torres <javier@javiertorres.eu>
Thanks @javitonino Working on release 3.11.11 now |
3.11.11 is now available with this fix |
What do these changes do?
Fixes a hang when reusing a connection that was previously used for a streaming download and returned to the pool in paused state.
Are there changes in behavior for the user?
No, aside from the bugfix.
Is it a substantial burden for the maintainers to support this?
No. This adds bit of extra code to ensure correctness in this case. It's covered by tests to ensure the behaviour stays through code changes.
Related issue number
Fixes #10169
Checklist
CONTRIBUTORS.txt
CHANGES/
folder