NIO can send channelInactive before channelActive reordered if user Channel.close()s in connect promise callback

[weissi]

Expected behavior

• channelInactive comes after channelActive
• channelInactive doesn't happen if channelActive hasn't happened

Actual behavior

It's possible to get channelActive following channelInactive.

Steps to reproduce

• Create an SSL channel that gets Channel.close()d really early on.

This seems related to apple/swift-nio-ssl#467

NIOSSLHandler observes the channel events in this order:

NIOSSLHandler sees the following channel events:

• handlerAdded
• close (triggered from a Channel.close())
• channelInactive (triggered from BaseSocketChannel.close0) [BUG HERE (channelInactive without channelActive)]
• channelActive (triggered from BaseSocketChannel.writable -> BaseSocketChannel.finishConnect -> BaseSocketChannel.becomeActive()) [BUG HERE (channelActive after channelInactive)]

Obviously those channel events are wrong. That's a bug in NIO too.

[weissi]

The issues is that the connect promise gets (by design) priority over fireChannelActive. The code's here:

swift-nio/Sources/NIOPosix/BaseSocketChannel.swift

Lines 131 to 132 in abbb144

	promise?.succeed(())
	pipeline.syncOperations.fireChannelActive()

        case (.fullyRegistered, .activate):
            self.currentState = .activated
            return { promise, pipeline in
                promise?.succeed(())
                pipeline.syncOperations.fireChannelActive()
            }

So NIO (like Netty) will always fulfil the promise first and then fire the channel pipeline event. That leads to this reorder:

• Channel.connect succeeds
• connect's promise gets fulfilled
• user calls Channel.close() in connect promise callback
• channelInactive gets called (because of the close)
• channelActive gets called once we move past the promise?.succeed(()) line

[weissi]

I think this is a rediscovery of #196 . Please note this comment: #196 (comment)