I’m seeing a consistent pattern when running a build of a large JS project makes a codespace completely unresponsive. After some time the codespace disconnects and then fails to reconnect back. The VSCode or online IDE is stuck in the “Opening remote” state and after a while the codespace is shut down.
Since you are using Codespace in your browser, a significant amount of RAM would be used in order to complete your tasks. Did you import node_modules into your project in Codespace? That might explain why it became unresponsive due to the large size of the project.
One solution would be to use a browser like Firefox which is capable of handling more browser load on less RAM. Also try using Firefox in a Linux based environment as it would further lower the RAM usage. I hope this works
Thanks, but connecting from the desktop version of VSCode has the same issue.
The build is happening on the codespace VM though and is affected by the amount of the RAM in the environment. Unfortunately, GitHub codespaces have only the smallest machine type available. I did the build on the original visual studio codespace service with larger machine type and it actually worked well, without interruptions.
I think that the GitHub codespaces team still can address the issue with overloading the VM hosting the environment. Ideally, the process responsible for running the remote stub of vscode and the VM networking should have a higher priority than any user-initiated tasks, so even if the VM is overloaded by the build the connection will stay uninterrupted.
Thanks for reaching out! As you discovered, it’s currently possible for your application/build process/etc. to consume enough CPU that it completely “starves” the Codespaces connection. This is something that we’re working to improve, and we’ll make sure to track progress in this thread.