-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
bpo-35998: Fix test_asyncio.test_start_tls_server_1() #16815
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
Conversation
main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it.
I tested manually this fix on my laptop using
I did a similar check on Gentoo's buildbot worker using using
|
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.
Thanks for fixing this tricky bug, @vstinner.
Great work!
This change needs to be backported to 3.7 and 3.8, but I prefer to wait to see if buildbots like this new change, before doing the backport. |
Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8. |
main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it. (cherry picked from commit fab4ef2) Co-authored-by: Victor Stinner <vstinner@python.org>
GH-16817 is a backport of this pull request to the 3.8 branch. |
main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it. (cherry picked from commit fab4ef2) Co-authored-by: Victor Stinner <vstinner@python.org>
…16818) main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it. (cherry picked from commit fab4ef2)
main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it.
main() is now responsible to send the ANSWER, rather than ServerProto. main() now waits until it got the HELLO before sending the ANSWER over the new transport. Previously, there was a race condition between main() replacing the protocol and the protocol sending the ANSWER once it gets the HELLO. TLSv1.3 was disabled for the test: reenable it.
main() is now responsible to send the ANSWER, rather than
ServerProto. main() now waits until it got the HELLO before sending
the ANSWER over the new transport.
Previously, there was a race condition between main() replacing the
protocol and the protocol sending the ANSWER once it gets the HELLO.
TLSv1.3 was disabled for the test: reenable it.
https://bugs.python.org/issue35998