This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients asvetlov, ned.deily, pablogsal, vstinner, yselivanov
Date 2018-06-07.08:37:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528360635.83.0.592728768989.issue33694@psf.upfronthosting.co.za>
In-reply-to
Content
Yury, Andrew, Ned: I set the priority to release blocker because I'm scared by what I saw. The START TLS has a race condition in its ProactorEventLoop implementation. But the bug doesn't see to be specific to START TLS, but rather to transport.set_transport(), and even more generally to transport.pause_reading() / transport.resume_reading(). The bug is quite severe: we loose data and it's really hard to know why (I spent a few hours to add many many print and try to reproduce on a very tiny reliable unit test). As an asyncio user, I expect that transports are 100% reliable, and I would first look into my look (like looking into start_tls() implementation in my case).

If the bug was very specific to start_tls(), I would suggest to "just" "disable" start_tls() on ProactorEventLoop (sorry, Windows!). But since the data loss seems to concern basically any application using ProactorEventLoop, I don't see any simple workaround.

My hope is that a fix can be written shortly to not block the 3.7.0 final release for too long :-(

Yury, Andrew: Can you please just confirm that it's a regression and that a release blocker is justified?
History
Date User Action Args
2018-06-07 08:37:15vstinnersetrecipients: + vstinner, ned.deily, asvetlov, yselivanov, pablogsal
2018-06-07 08:37:15vstinnersetmessageid: <1528360635.83.0.592728768989.issue33694@psf.upfronthosting.co.za>
2018-06-07 08:37:15vstinnerlinkissue33694 messages
2018-06-07 08:37:15vstinnercreate