Crash fix: HTTP2Connections emit events after the pool has closed them.#481
Conversation
glbrntt
left a comment
There was a problem hiding this comment.
Looks good, just a comment/question.
| // Connections report events back to us, if they are in a shutdown that was | ||
| // initiated by the state machine. For this reason this callback might be invoked |
There was a problem hiding this comment.
This doesn't quite make sense to me. I think you're saying that we can still receive events after shutdown was initiated by the state machine, and when that happens http2Connections will be nil and we can safely ignore the event?
There was a problem hiding this comment.
I think it'd be worth adding a comment where http2Connections is declared on L31 saying when we expect it to be nil.
There was a problem hiding this comment.
I also wonder if http2Connections ever needs to be nil -- presumably we can just remove all connections from it?
There was a problem hiding this comment.
I think the only reason why we made it optional was to free some memory early. I think it would make the code clearer if we make it non-optional e.g.: after we have closed a connection we set it to nil if it is empty.
Instead we could just check if it is empty in all places where we currently check that it is nil e.g. during shutdown and make
http2Connections non-optional.
The same is true in the HTTP2StateMachine for http1Connections.
dnadoba
left a comment
There was a problem hiding this comment.
This should fix the issue, thanks! New test cases look also good for HTTP2Connections and HTTP2StateMachine. Just one nit: maybe we should also add one test case for the HTTP1StateMachine.
On the swift-server slack a crash was reported:
The problem here is: HTTP2Connections continue to emit events even after the pool has decided to shut them down, since the connections reference the pool as a
let delegate. The pool must be resilient enough to ignore these events.