-
Notifications
You must be signed in to change notification settings - Fork 6.3k
-
Hello everyone (and mostly @code-asher).
I am in the process of creating a PR for the vscode extension for Evidence, an awesome reporting tool, here evidence-dev/evidence#3201
The issue I am facing is that depending on whether the user is using vscode locally or via code-server, providing a seamless experience requires different measure.
Namely, unlike in native vscode, port forwarding works entirely differently in code-server. This is an important distinction for someone running the extension on a remote machine using code-server from Coder.
Is there a way to detect that we are running inside of a code-server, as compared to vscode natively, and what is the recommended way to interact with the auto port forwarding feature. Namely, when the user does not specify a preferred port or when the port is occupied and the command ends up running on a different port. This is a time where probing the auto forwarder asking for the actual port can be of great use.
Any level of information or a hint into where to look would be great.
Kind regards,
Orwa.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment 4 replies
-
After posting the message above, I stumbled upon this https://code.visualstudio.com/api/advanced-topics/remote-extensions which explained a lot, however, I still have more questions.
I learnt more about auto port-forwarding and the function vscode.env.asExternalUri which gives back the port-forwarded URL's (ending with /proxy/{{port}}) but there is something that I still do not understand.
Namely, I have been struggling with performance issues in code-server which got me thinking about memory leaks and how most extension developers do not think about remote development. One unique thing about remote development is that you can close the window anytime. Namely, I do not see how the extension can get any time to cleanup.
In the code of the extension I am creating a PR for, there are a lot of so-called disposables, and I want to know if these are compatible with extensions running in a workspace remotely using code-server.
Any hints or links that you can offer me will be highly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions
-
Yeah back when I investigated this (a long time ago now), when the browser window closes the extension host process is immediately killed, and extensions are given no time to clean up. I am pretty sure the disposables are never called, or at least they were not last I checked. Not sure if things have changed since then, but it sounds like they have not.
The VS Code folks would know more, but I think this is where it happens: https://github.com/microsoft/vscode/blob/bf0108fb1e1321b025449650e6710f18116d5e64/src/vs/server/node/remoteExtensionHostAgentServer.ts#L477
When the connection is closed, the extension host is disposed, which if you follow through appears to immediately kill the process: https://github.com/microsoft/vscode/blob/bf0108fb1e1321b025449650e6710f18116d5e64/src/vs/server/node/extensionHostConnection.ts#L231
Ideally, it would let all the extensions clean up first. Unless that changes, I think extensions will have to consider they could be killed at any time. Of course, this is good practice anyway since a process can crash unexpectedly, but it does seem like a bug given how native VS Code works versus web VS Code. Assuming I am looking at this right, I could be wrong about it all. I am not actually sure disposals work consistently in even native VS Code.
Beta Was this translation helpful? Give feedback.
All reactions
-
😕 1
-
Beta Was this translation helpful? Give feedback.
All reactions
-
I greatly appreciate this response. So what you are saying that this is completely vscode territory since vscode is supposed to run correctly either as a standalone application or as a web application. Please correct me if I am wrong.
The "folks" at vscode seem quick to assume that it is code-server that is the cause of issues, rather than the underlying technology, though: microsoft/vscode#267668 (comment)
How can I navigate this as an open-source consultant/volunteer/advocate. I have started relying on code-server heavily but what I am hearing is that it is not ready, or at least that the remote extension system in vscode is the cause of the issue. This seems really odd considering that GitHub codespaces relies on this and that this has been a design objective for a while.
Is this something that you are open to fixing temporarily through patches, and then work on getting the vscode team to incorporate them after they are proven to be correct? Maybe this is a way where third-party advocates like myself can come in? I would like to hear your thoughts.
PS: the first step, obviously, is to investigate the same thing you investigated a while ago and see what the current behaviour is in Code when it comes to remote extension's cleanup
Beta Was this translation helpful? Give feedback.
All reactions
-
❤️ 1
-
So what you are saying that this is completely vscode territory since vscode is supposed to run correctly either as a standalone application or as a web application
Yup that is exactly right. We add and patch a few things to make it easier to self-host but it is actually possible to run VS Code as a web application directly without our patches using native VS Code with code serve-web.
The "folks" at vscode seem quick to assume that it is code-server that is the cause of issues
Ah yeah this can be tricky. When it comes to opening a bug report upstream, you definitely want to reproduce with code serve-web and/or Codespaces (or even vscode.net for purely UI issues), otherwise it is too easy for them to dismiss it as a code-server issue.
And there is always the possibility that it is actually a code-server issue (maybe we patched something that had an unexpected side effect for example), so always good to check anyway.
Is this something that you are open to fixing temporarily through patches, and then work on getting the vscode team to incorporate them after they are proven to be correct
I would generally prefer the reverse order, submit the pull request to VS Code and then if they are not receptive to it, then we consider maintaining it as a patch here. Mostly because, they know the system much better, so it is possible that they ask for fundamental changes, and now we are stuck with a less-optimal patch in code-server, possibly even causing a breaking change one day when we then try to upgrade the bundled VS Code version.
This seems really odd considering that GitHub codespaces relies on this and that this has been a design objective for a while
Agreed, I am not sure if Codespaces is not a high priority or what exactly the deal is. There seem to be a few issues around reconnecting, like this one that reproduces in Codespaces and code serve-web: #7447 People also commonly report copy/paste issues, keybinding issues, memory usage problems, and more.
Beta Was this translation helpful? Give feedback.