SSLProtocol violates app Protocol state machine

[jeremy-hiatt]

• uvloop version: 0.12.2
• Python version: 3.5.4
• Platform: Mac OS X
• Can you reproduce the bug with PYTHONASYNCIODEBUG in env?: Yes

Some instances of the Protocol class assume connection_lost() can only be called if connection_made() was called at some point. This does not appear to be explicitly guaranteed in the Python documentation, but the following comment strongly suggests that intent:
https://github.com/python/cpython/blob/master/Lib/asyncio/protocols.py#L84

An error raised during the handshake phase triggers a transition back to UNWRAPPED:
https://github.com/MagicStack/uvloop/blob/master/uvloop/sslproto.pyx#L504
Following this code path further, we see that it will force close the transport, which triggers a call back to SSLProtocol.connection_lost(). This is then forwarded onto the app's Protocol instance, even though connection_made() was never called.

Would it be appropriate to change the following guard to also exclude the UNWRAPPED state?
https://github.com/MagicStack/uvloop/blob/master/uvloop/sslproto.pyx#L337
Alternatively a boolean value could be used to track whether or not connection_made() has ever been called.

[1st1]

@fantix any thoughts?

[fantix]

Yes, it makes perfect sense to honor the CM -> ... -> CL state machine, I don't see a reason why not to. Thanks for the very detailed report and 2 proposals! I think the boolean value is the right way to go - WRAPPED, FLUSHING or SHUTDOWN may transit to UNWRAPPED before connection_lost() is called.

[1st1]

@fantix Do you plan to implement this yourself?

[fantix]

Yes! I'll create a PR for that.

[1st1]

@fantix ping

[fantix]

Ahhh that slipped through the cracks, let me make one PR now.