Fix port forward issues on Windows #2218
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2129 (which turned out only partially to have to do with hot reloading, specifically)
I found two problems that relate to the issue, both pretty subtle.
One was that the subprocesses used for k8s port forwards could in some cases hang around after the main process closes. I think the first commit takes care of that, at least I couldn't get it to come up again after the change.
Second was that we weren't properly catching the EADDRINUSE error from the proxy server we create as soon as we allocate the proxy (i.e. even before the underlying port-forward is started).
The reason this issue had eluded us during testing appears to be that it only came up on consecutive runs of Garden, where Garden would attempt to get the same port again on the next run, but Windows appears to reject that until after some time has passed (if I wait more than a minute, the ports go back to where they "want" to be).