This repository has been archived by the owner on Aug 31, 2023. It is now read-only.
fix(rome_bin): improve error handling for Unix domain sockets #3137
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes how the domain socket file used to communicated between the daemon server and workspace clients is handled.
Specifically, since the file is left behind in the system temporary directory when the daemon process is killed, the
open_socket
needs to handle theConnectionRefused
error in the same way as theNotFound
error and consider the daemon is not running.I also extended this behavior to the
print_socket
with an additional safeguard as it will only try to connect a limited number of times before failing with the last error reported by the system.Finally, since the server cannot bind to an existing file I added a call to
remove_file
on the domain socket file if it exists when therun_daemon
function is calledTest Plan
I tested this manually using Ubuntu on WSL: I checked that after spawning the server process with
cargo rome-cli-dev __run_server
then killing it, the main CLI started withcargo rome-cli-dev format editors/vscode/src/main.ts
was not using the daemon server nor failing to initialize a connection, and the server process could be started again without failing on the pre-existing socket file. I guess it would probably benefit from being tried out on a macOS machine, as well as a "physical" Linux setup instead of the "virtual" Windows subsystem