A bad messaging socket path now fails with a clear error instead of being silently ignored.
What's wrong with this entry?
Passing an unusable socket path used to be logged and ignored. It now fails with a user-facing error naming the flag, spelling out what was rejected: a remote or UNC path, or a pipe name with extra segments or a trailing dot or space.
- The refusal is recorded as a start-failure cause
path_refused; when the path did not come from the flag explicitly, it is recorded without throwing. - Storage is now threaded through peer sends and shutdown, so peer notices and hold receipts carry it.
not a usable local socket address (a remote/UNC path, or a pipe name with extra segments or a trailing dot/space)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.232
Clearer failures when the messaging socket path is unusable
Both mention socket path
-
v2.1.224
Session info reports the messaging socket path
Both mention socket path
-
v2.1.224
Local messaging socket: where it lives, who can read it, and refusing to steal a live one
Both mention socket path