We support connecting to previous workspaces, but sometimes this breaks because the previous workspace belongs to a different deployment, and the plugin always uses the credentials of the current deployment (https://github.com/coder/vscode-coder/issues/173).
This is a first step to fixing that: separating the client into two: one used by the plugin as a whole (mainly used to list workspaces of the current deployment in the sidebar) and one used to connect to a workspace which may belong to a different deployment (which is used to start the workspace, get the version, etc). Thankfully this is pretty chill since @Parkreiner's changes to Coder core!
For now that second client does still use the global url and token so functionally it is still the same, but I will fix that in a follow up PR by looking at the host name and figuring out the right credentials to use for it.
As part of this, I try to remove usage of a few globals, in particular we had stuff like storage.getSessionToken() all over the place, now I only call that once when creating a client and we use it for the lifetime of the task.
Alternatives
Instead of creating a separate client, we could log the entire plugin in to the right deployment. So if you are connected to deployment A, then connect to a workspace belonging to deployment B, the plugin would now entirely be logged into deployment B.
That felt a little too unexpected to me, so I went with the multiple client route.
But maybe it would be better to do a full login, because then the workspaces you see in the sidebar belong to the same deployment.
Still, I think these changes are generally good anyway because they are getting rid of a bunch of global stuff. We can do a full login if we want to with these changes as well.
We support connecting to previous workspaces, but sometimes this breaks because the previous workspace belongs to a different deployment, and the plugin always uses the credentials of the current deployment (https://github.com/coder/vscode-coder/issues/173).
This is a first step to fixing that: separating the client into two: one used by the plugin as a whole (mainly used to list workspaces of the current deployment in the sidebar) and one used to connect to a workspace which may belong to a different deployment (which is used to start the workspace, get the version, etc). Thankfully this is pretty chill since @Parkreiner's changes to Coder core!
For now that second client does still use the global url and token so functionally it is still the same, but I will fix that in a follow up PR by looking at the host name and figuring out the right credentials to use for it.
As part of this, I try to remove usage of a few globals, in particular we had stuff like
storage.getSessionToken()all over the place, now I only call that once when creating a client and we use it for the lifetime of the task.Alternatives
Instead of creating a separate client, we could log the entire plugin in to the right deployment. So if you are connected to deployment A, then connect to a workspace belonging to deployment B, the plugin would now entirely be logged into deployment B.
That felt a little too unexpected to me, so I went with the multiple client route.
But maybe it would be better to do a full login, because then the workspaces you see in the sidebar belong to the same deployment.
Still, I think these changes are generally good anyway because they are getting rid of a bunch of global stuff. We can do a full login if we want to with these changes as well.