Closed roblourens closed 8 months ago
As in the stack, resolveExecServer
is getting called by the remote containers extension trying to get the exec server. So that call is expected, and it will download a 'duplicate' server in the case that the primary connection to the remote is not using the exec server already. If the primary connection is working and is exec server based, then no new connection is made.
Remote containers doesn't actually require a VS Code server until it opens a workspace, only an exec server, so it may not have gotten to the same download failure that the traditional connection did when it tried to install the VS Code server.
So while this scenario looks a little weird, things seem to be working as expected...
It seems like you shouldn't call resolveExecServer
when the initial resolve failed though, and so the window is not connected anyway.
Also, why does the remote container extension do this even before I'm using any remote container features? Seems like this would be an expensive call and we shouldn't do it eagerly. If I use password auth I think I'll get another password prompt.
It seems like you shouldn't call resolveExecServer when the initial resolve failed though, and so the window is not connected anyway.
This is called via the API from remote containers -- perhaps it should wait until resolution.
Also, why does the remote container extension do this even before I'm using any remote container features? Seems like this would be an expensive call and we shouldn't do it eagerly. If I use password auth I think I'll get another password prompt.
If there's already an exec server connection available, no extra work is done during connection. I believe dev containers does a feature probe to see what context keys and e.g. commands it should enable; Martin would know more.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
This is called via the API from remote containers -- perhaps it should wait until resolution.
I think it should- is that for the extension or for the vscode API implementation?
If there's already an exec server connection available, no extra work is done during connection.
Yeah, but it can be annoying for users who aren't using exec server mode, while we are still in that state
is that for the extension or for the vscode API implementation?
Preferably in the extension, I would rather not special case logic in vscode's resolvers for this, cc @chrmarti
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
Seems that after we fail to connect to the remote,
resolveExecServer
is called which kicks off a second round of trying to connect in the background. Here's the log and also the stack of the call toresolveExecServer
, from the dev containers extension.But also, it looks like when the connection was successful and we do this again, it leads to a second
ssh
call and a second local server? That seems wrong too, I realized I don't understand this flow that well.