Half close port forwarding connections to fix hangs#6888
Conversation
|
👋 @josebalius I know this isn't your space anymore, but you're probably the expert on this code still 😅 If you still have context, would appreciate confirmation on my understanding of how the flow works - thanks! |
josebalius
left a comment
There was a problem hiding this comment.
Makes sense, although not sure why we need a half closer, can't we close both the read and write?
|
While you're working on this @cmbrose, note that port forwarding tests have been disabled in CI due to being flakey cli/pkg/liveshare/port_forwarder_test.go Line 37 in 71ec2c4 |
@josebalius we need to keep the read side open so that the local side can still write a reply after the codespace finishes the response. That flow would look like this:
This PR specifically adds the logic in step 6. Without that new logic, step 8 can hang forever as the app may think the codespace might have data to send still. The need to only half close the TCP connection is to support the scenario in step 7. If we fully closed the connection in step 6 then the local app couldn't send additional data to the codespace after getting the response. |
Thanks for the heads up! Ran locally and looks good |
thomas-sickert
left a comment
There was a problem hiding this comment.
Just had one question about reusing a method, other than that, functionality LGTM 👍
Fixes: #6842
See the comment here for a full explanation of the bug: #6842 (comment)
The core change here is to close the write side of the
net.Connto the client in order to signal that client that the response is complete.The base
net.Connhowever doesn't expose a function to close only the writer, so everything is changed to usenet.TCPListenerwhich does. The bulk of the change is to support that a little more cleanly.