BrianHotoppandClaude Fable 5
bcd7fe1fbc
Any IOException while creating the boot io socket was wrapped in ServerAlreadyBootingException and reported as "sbt thinks that server is already booting" with a stack trace, and non-interactive invocations exited with code 2. Permission or path-length problems with XDG_RUNTIME_DIR or the temp directory and Windows named-pipe access errors all hit this, blocking sbt entirely (#6777). Raw IOExceptions from the constructor (socket directory creation) were not caught at all and crashed startup. getSocketOrExit now connects to the socket (BootServerSocketProbe, shared with the test suite) to check for a live server before believing the exception. Co-authored-by: Claude Fable 5 <[email protected]>
913 B
sbt no longer refuses to start when the boot socket cannot be created
Failures to create the boot-time io socket used to be misreported: most were
wrapped as "sbt thinks that server is already booting" with a stack trace, and
non-interactive invocations exited with code 2, while failures to create the
socket directory crashed startup outright. Permission or path-length problems
with XDG_RUNTIME_DIR or the temp directory and Windows named-pipe access
errors all hit one of these (#6777).
sbt now probes the socket first. Only a live server answering the probe is treated as another sbt booting in the build (the interactive prompt and non-interactive exit are unchanged, with a clearer message). Any other failure is no longer fatal: sbt continues without the boot socket, whose only job is forwarding boot-time io to early-connecting clients.