🐛 __print_socket error: Operation not supported within DevContainer #273
Comments
|
Thanks for the report. Would you mind providing a reproduction repo that contains the devcontainer configuration already set up ? |
|
Sure! Here is a minimal repro where I just tested that it still happens: https://github.com/ffMathy/biome-repro-1 Remember to start the project in the Dev Container. I also think it is necessary to run it from a Mac machine. Here are my Docker settings: |
|
Hey, I appreciate you taking the time. However, I'm not able to start the dev container because some mounts seem to be missing. It looks like this may be related to your personal setup. If you could provide a minimal setup, it would go a long way. |
|
Actually I don't think the mounts are needed to repro it. I just forgot to remove those. |
|
@nhedger any update given my reply? I updated the repro now to remove the bind mounts. |
|
We will fix this in v3 #201 |
|
Should be fixed in the latest nightly. |
|
@nhedger this is still an issue in the latest nightly. Can you reopen this? Log output (from "Biome LSP"): |
|
I can now confirm that only our Mac users are having this issue. The people with Windows work just fine. |
|
Thanks for the deets, I'll try to reproduce it later today |
|
Because Biome is installed globally using PNPM and the extension's Path Environment strategy is resolving the Biome binary to This fails because There are a couple of solutions:
|
|
I already have it installed in my project's dependencies too, as well as global. It's still happening. |
|
The reproduction you provided did not include project dependencies. Please update your reproduction with the relevant setup. |
|
Alright, fair enough, but then I tried installing the package with the Dockerfile command you provided. Here's the log output: |
|
I see that you devcontainer config also references the latest stable version of the extension. Have you tried with the pre-release ? "customizations": {
"vscode": {
"extensions": [
- "biomejs.biome"
+ "biomejs.biome@prerelease"
]
}
}, |
|
Yeah, what I just do when I start up is to manually go in and switch to prerelease in the Extensions tab after the dev container has been built the first time. My version in the above was: v2024.9.91939 |
|
I'm wondering if that leaves the devcontainer in a weird state. When I start it with the |
|
Do you have the same settings in Docker as I posted above in the screenshot? More specifically, I am suspecting the "filesystem" part might be relevant. Edit: Changing to |
|
I wish the extension could somehow debug on which line it's happening. Is that possible to retrieve somehow? Then maybe I can also help a bit. |
I actually run OrbStack by default, but I just installed Docker Desktop and confirm that it works even with the same Docker settings as shown in your screenshot.
It is possible to debug the extension, but I don't know how/if this works in a devcontainer. Edit: looks like it's possible, I pushed a devcontainer config to the repo if you'd like to try and reproduce. |
|
I tried starting the project from the DevContainer. I get this error: Also, did you click "Reopen in Container" or "Clone in Volume"? I always use "Clone in Volume" because it's way faster. That is required by my own project. Perhaps that's what makes it so that you can't repro? |
|
After switching away from PNPM to Bun, all my issues (even with the old Biome) went away. So must be related to how node_modules gets built. In our project, we also had a |
|
Okay, it started happening again. Interestingly, when it happens, if I rebuild the DevContainer, it stops happening. I noticed that by running tests a lot, we open a lot of ports. Could it have something to do with it trying to open sockets, but being exhausted due to some maximum socket count? Does Biome try to communicate with any form of network connection somehow? |
|
The current version of the extension does communicate with the Biome Daemon via sockets. I suggest you try the preview release of the extension, which changes the way the extension connects to the Daemon (it won't use sockets anymore) |
|
Then I don't think sockets is the root cause. Because when I was using the prerelease version earlier, it'd fail in the same way with the same error. Right now, switching to the prerelease version of Biome does indeed work, but then again, I also currently can't repro the issue with the old stable version of Biome. So let's leave this issue open until it happens again, and I can fully decide if switching to the prerelease will work. But since I do not believe it will, can we theorize as to what might then be causing it? What kind of file-related operations is the Biome VS Code extension trying to do? Can it have something to do with symlinking, binary aliases, long path names, or something similar? |
|
Can we insert more logging to maybe find the cause? Any suggestions on how I can help? ❤️ |
|
I'd like to focus on releasing the current prerelease as stable. In your previous you mentioned switching to the prerelease kinda solved it. Are you now experiencing it also on the prerelease ? If so, we can try adding some more logging when we create the LSP session. |
|
It still happens on the pre release. For both prerelease and current stable, it doesn't happen if I rebuild my container without cache and reinstall all my dependencies. Never tried just one of those, so not sure which one solves it. But then after some time, it starts happening. Also on prerelease. The latest logs I posted were from the prerelease. |
|
Here's another prerelease log of this happening: |
|
I am not very familiar with "dev containers", but if they rely on web technologies (e.g. JS + WASM) to run the extensions, then all these errors are expected. |
|
They do not. They run in Docker, on a full Docker container. You can read more here: https://containers.dev/ It's an open standard that is adopted by VS Code, but is also soon adopted by JetBrains IDEs. |
|
So, the OS error 95 hints at the fact that the dev container doesn't support sockets. However, this is just a wild guess, so I might be wrong |
|
But doesn't the pre-release get rid of sockets? It still happens on pre-release. And DevContainers do support sockets. They are just Docker containers. Anything supported in Docker will run just fine. Also, it doesn't explain why it works initially, but then (over time) doesn't work anymore. Can we insert more log statements to figure out exactly where it is happening? |
|
Here's something interesting. It's python, but should still be relevant. So apparently it can happen if you perform an operation on a working directory that doesn't exist. Could this be inside the binary locator? Again, way more logging could help out a ton. |
|
Probably that part of the code doesn't have much logging, but here: |
|
The problem is that this only enables logging in Biome itself from what I read? I am 100% sure the problem is not in Biome itself. We also have a pre-commit hook that runs the Biome CLI. It works every single time. This happens in the VS Code extension code, not Biome. Since you say that code doesn't have much logging, does it make sense to add it perhaps? Just with a low enough log level, so we can see where it is failing. |
|
Biome has a lot of logging, but the part that bootstraps the Daemon doesn't |
|
Yes, I know. That's actually my point with these past comments:
Sorry, I am not sure how I can be more clear here. I was actually asking if it would make sense to add more logging. If you believe so, I am willing to help out and contribute with such a PR 😄 |
|
Oh yeah, that's definitely a welcomed PR! |
|
Just had this happen in Windows as well, but not with prerelease: [Error - 5:52:57 PM] Biome client: couldn't create connection to server. Reloading client failed: Error: Command "/usr/local/share/npm-global/bin/biome __print_socket" exited with code 0 |
|
More information has arrived. Not sure why it's copying to that destination. That destination is inside VS Code's DevContainer files. I think this could be the root cause. It should copy to another directory, perhaps preferably inside |
|
I also had this error. Could be of interest. I think it's an error in the logger somehow. It's trying to call toString on some undefined error value. If this was solved, I believe I could get more information out of it. |
The destination is inside the container due to how vscode-server works. This is a location provided by the VS Code API that extension authors can use to store global data related to the extension. I'm unsure if this is why it fails, though. You could try to change the location and compile your own version of the extension to check if it happens when using a different destination. |
|
What I find very strange is that none of the log statements I added in a recent PR are shown. How can I verify that I was using the right version with that included? |
|
Make sure you're using the latest pre-release version. Also, ensure that the logging level is set to Debug to see the debug logging. |
VS Code version
1.91.1
Extension version
2.3.0
Biome version
0.3.3
Operating system
Description
Steps to reproduce
Use the following Dockerfile as your DevContainer in VS Code, with the "dev-container" multi-stage image as the target:
I am running Docker on Mac, but the image is a Linux image.
Expected behavior
I expected it to not fail.
Does this issue occur when using the CLI directly?
Not sure / Not applicable
Logs
The text was updated successfully, but these errors were encountered: