code-server -r filename results 'error Unexpected status code: 500'

[krisek]

Is there an existing issue for this?

• [X] I have searched the existing issues

OS/Web Information

• Web Browser: Chrome
• Local OS: Debian testing
• Remote OS: Debian testing
• Remote Architecture: amd64
• code-server --version: 4.92.2 de65bfc9477f61bc22d0b1a23085d1f18bb25202 with Code 1.92.2

Steps to Reproduce

1. Open code-server
2. Open an existing workspace
3. Open a file from CLI (code-server -r ...)

Expected

code-server opens the specified file in one of the open windows.

Actual

Some cases it works, mostly with fresh sessions, then after a while it breaks and I get only a error Unexpected status code: 500. I just realised that restarting the code-server instance and reloading the client window fixes the problem.

Logs

As an intermittent issue I need to work a bit on the logs, I set verbose now.

Screenshot/Video

No response

Does this bug reproduce in native VS Code?

I did not test native VS Code

Does this bug reproduce in GitHub Codespaces?

I did not test GitHub Codespaces

Are you accessing code-server over a secure context?

• [X] I am using a secure context.

Notes

No response

[kova98]

Have you resolved this? I have the same issue, nothing in logs either (verbose mode).

[code-asher]

In the integrated terminal, VS Code usually provides its own code-server binary. Is that the one being ran, or is it the one we ship? What does which code-server show?

Either way, it makes a POST request against the VS Code socket stored in the VSCODE_IPC_HOOK_CLI environment variable. I am not sure why this would error though, unless the socket somehow went away?

[krisek]

Have you resolved this? I have the same issue, nothing in logs either (verbose mode).

Nope, still occurs from time to time.

In the integrated terminal, VS Code usually provides its own code-server binary. Is that the one being ran, or is it the one we ship? What does which code-server show?

I always use separate terminal window, /usr/bin/code-server is used.

Either way, it makes a POST request against the VS Code socket stored in the VSCODE_IPC_HOOK_CLI environment variable. I am not sure why this would error though, unless the socket somehow went away?

This is interesting as VSCODE_IPC_HOOK_CLI is not defined in the terminal outside code-server, while it is there in the built in terminal.

And here comes fun:

❯ touch a
❯ code-server -r  a
[2024-10-29T19:47:24.724Z] error Unexpected status code: 500
❯ VSCODE_IPC_HOOK_CLI=`ls -1t /run/user/$(id -u)/vscode-ipc*.sock | head -1` code-server -r a
❯ echo $?
0

ie. it opens with VSCODE_IPC_HOOK_CLI set. Interestingly there are 36 sockets in /run/user in my case, I simply chosen the newest.

🤔 I can accept this as a solution, I just need to add to my rc the above and we are good.

[code-asher]

Ahhhh I see, yup if you use it outside of the integrated terminal and there is no VSCODE_IPC_HOOK_CLI variable set, then it will instead use our own socket which defaults to code-server-ipc.sock in the user data directory (by default ~/.local/share/code-server).

There could definitely be a bug here. Or maybe if there was a second code-server instance spun up, it would take over that socket, and then if closed it would no longer be handling it, and there is no way for the older instance to take over again. Just one way this might happen, at least. We might need logic to gracefully handle multiple code-server instances, if this is what is happening.

Setting VSCODE_IPC_HOOK_CLI seems like a reasonable workaround.