fix node.sock detection from docker#147
Conversation
|
I strongly believe we should push a PATCH release today with this fix, since it's a problem which has been already signaled by some users. |
|
To test this PR, you have to do the following:
|
GitGab19
force-pushed
the
fix-node-sock-detection-from-docker
branch
3 times, most recently
from
fde96d0 to
fe9bfd8
Compare
Shourya742
left a comment
Shourya742
left a comment
There was a problem hiding this comment.
Tested locally, works fine with the current changes. It is able to pick up the socket path on the host.
|
@Shourya742 you're also on Linux, right? It seems we're having issues on macOS though.. |
Yup on linux... worked fine |
GitGab19
force-pushed
the
fix-node-sock-detection-from-docker
branch
from
fe9bfd8 to
a14d8c0
Compare
Validate configured Bitcoin Core IPC sockets from inside Docker by probing through a short-lived helper container with the host socket bind-mounted. Also revalidate the socket before setup, config update, and restart so a node crash between wizard validation and stack startup fails cleanly instead of starting a broken JDC container.
Add retry support for transient Bitcoin socket validation failures and surface Open Bitcoin Setup actions from setup, settings, and dashboard error states. Centralize Bitcoin socket error matching so recovery UI and retry behavior use the same predicates.
GitGab19
force-pushed
the
fix-node-sock-detection-from-docker
branch
4 times, most recently
from
64d8f0c to
f58ebbe
Compare
|
Works on my mac |
|
@lucasbalieiro I just pushed 70cd24b which is able to get if the socket is listening for real (Bitcoin Core is running) without having to run JDC in a temporary container as done by f58ebbe. I tested multiple times and it works like a charm, please let me know if it's the same on your side. If you agree, I would simply drop f58ebbe in favor of this last 70cd24b which is way simpler. |
When sv2-ui runs in Docker, attaching the container to sv2-network during setup can briefly interrupt the in-flight /api/setup request even though the backend successfully starts JDC and Translator. After a fetch, network, or timeout error on the final setup step, check /api/status and show the success screen if the stack is already configured and running.
GitGab19
force-pushed
the
fix-node-sock-detection-from-docker
branch
from
64ae58e to
d1bfaa5
Compare
|
@lucasbalieiro now the PR is in its final shape, I tested multiple times on both macOS and Linux, and everything works perfectly. If you approve it, I'll proceed with the PATCH release. |
lucasbalieiro
left a comment
lucasbalieiro
left a comment
There was a problem hiding this comment.
tACK d1bfaa5
Did a final build/test to see if nothing went wrong during the rebase and drop of the prevous commit. It worked
3 participants
In #90 we introduced a validation process during Bitcoin Core setup.
The problem is that while it's working when running
sv2-uiwithnpm run dev(because it has access to the host), it doesn't work when launchingsv2-uiinside docker (what our users are doing as suggested on our website).And the reason is that the container in that case doesn't have access to the host, so it's not able to find the
node.sockfile, even though the node is running and the socket file exists in reality:This PR addresses that by validating the socket path from the Docker runtime instead of from the
sv2-uicontainer filesystem.Implementation notes:
node.sock.Binds, matching how the JDC container mounts the same socket at runtime.connect()/stat()calls can returnENOTSUPfor host-mounted Unix sockets. In that case, the validator falls back to a short-lived probe using the selected JDC image, a temporary JDC config, and the same socket bind path JDC uses at runtime.node.sockfile left behind after Bitcoin Core stops is rejected instead of treated as valid.In case the socket is not active, the setup UI shows an error and automatically retries retryable failures every 5s.
Screencast.From.2026-05-07.10-40-55.mp4