Race updating coder binary

[aaronlehmann]

There appears to be a race in the Coder VSCode extension where using mulitple VS Code windows connected to different workspaces can try to update the coder binary at the same time, resulting in failures:

Error: ENOENT: no such file or directory, rename '/Users/mkrasnow/Library/Application Support/Code/User/globalStorage/coder.coder-remote/bin/coder-darwin-amd64' -> '/Users/mkrasnow/Library/Application Support/Code/User/globalStorage/coder.coder-remote/bin/coder-darwin-amd64.old-rtvak' 

Error: ENOENT: no such file or directory, rename '/Users/mkrasnow/Library/Application Support/Code/User/globalStorage/coder.coder-remote/bin/coder-darwin-amd64' -> '/Users/mkrasnow/Library/Application Support/Code/User/globalStorage/coder.coder-remote/bin/coder-darwin-amd64.old-5oo5n'

[aaronlehmann]

I've only seen this happen in VS Code, but it may also be an issue with the JetBrains Gateway plugin, so it would be worth checking there as well.

[johnstcn]

Given that we can have multiple deployments with different versions, it would make sense to store the Coder binary in a separate directory or file prefix per deployment.

There is a separate issue where the initial "rename" of the existing binary is racy. My experience with implementing coder update in the previous version of Coder Enterprise is that this step is only necessary on Windows, and that on Darwin/Linux platforms we can just write the updated binary to a new file, and then move, overwriting the running binary.

[EhabY]

Seems to be a duplicate for https://github.com/coder/vscode-coder/issues/575 or at the very least closely related.

I think now we always place binaries in their deployment folder (uses the URL as a folder name) so this only happens when connecting to the same deployment in multiple windows.

[EhabY]

Fixed by https://github.com/coder/vscode-coder/pull/656