fix: accept absolute unix socket paths in GrpcEndpoint - #1226
Kayvan-Zahiri wants to merge 3 commits into
Conversation
unix:///path/to.sock and unix:/path/to.sock put the socket path in the parsed URL's path, which the path check rejected, so WorkflowRuntime, DaprWorkflowClient and DaprClient all failed on them. Allow a path for the unix scheme and build the hostname from netloc + path so the filename's case is kept. Signed-off-by: Kayvan Zahiri <kzahiri@dons.usfca.edu>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1226 +/- ##
=======================================
Coverage 83.89% 83.90%
=======================================
Files 123 123
Lines 10265 10270 +5
=======================================
+ Hits 8612 8617 +5
Misses 1653 1653 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
CasperGN
left a comment
There was a problem hiding this comment.
Thanks, the fix is in the right place and the new tests fail without it. I also confirmed against a real gRPC server that the unix:/abs, unix:///abs and unix:rel targets now connect. A few things before merging:
1. unix://relative/path is now accepted but can never connect.
Before this PR, unix://relative/dir/x.sock failed at parse time with a clear error. Now it passes through unchanged, gRPC logs authority-based URIs not supported by the unix scheme / target uri is not valid, and the client hangs until its timeout. gRPC requires unix:// to be followed by an absolute path. Could you raise a ValueError when the scheme is unix and netloc is non-empty (e.g. "unix:// endpoints require an absolute path; use unix:relative or unix:///absolute"), and add a test for it?
The existing 'unix://my.sock' case in helpers_test.py has the same problem (gRPC rejects it for the same reason). That one predates this PR, but the same check would cover it.
2. Relative socket names are still lowercased.
unix:My.sock still becomes unix:my.sock, because that form has no path and still goes through parsed_url.hostname. Building the hostname from netloc + path for every unix endpoint would make both forms keep their case. Fine as a follow-up if you'd rather keep this PR narrow.
3. Minor, non-blocking:
unix:///tmp/x.sock#fragsilently drops the fragment. It's harmless, but it's the only part of the address dropped without an error.- The deprecated
DaprClient.wait()does a TCPconnect((hostname, port)), so it can't work with any unix endpoint. This predates the PR; just noting it.
gRPC needs an absolute path after unix://, so unix://my.sock and unix://rel/dir/x.sock can never connect; raise ValueError instead of hanging until the timeout. Build the hostname from netloc + path for every unix endpoint so unix:My.sock keeps its case. Signed-off-by: Kayvan Zahiri <kzahiri@dons.usfca.edu>
da72777 to
b563a2a
Compare
|
Thanks for testing it against a real server. Done in b563a2a:
I left the fragment and |
Description
An absolute Unix socket endpoint like
unix:///tmp/dapr.sock(orunix:/tmp/dapr.sock) makesGrpcEndpointraise "paths are not supported for gRPC endpoints", because urlparse puts the socket file path in the URL's path component and_validate_path_and_queryrejects any path.unixis listed as an accepted scheme, so this was only usable with relative names likeunix:my.sock.The fix allows a path when the scheme is
unix, and builds the hostname from netloc + path. Using netloc + path instead ofparsed_url.hostnamematters becausehostnamelowercases, which would point at the wrong file for a name likeDapr-MyApp-grpc.socket.Since
WorkflowRuntime, bothDaprWorkflowClients andDaprClientall go throughGrpcEndpoint, this fixes all of them, not only the workflow constructors in the issue. Other schemes still reject paths.Tests: new parser cases (both absolute forms, TLS, mixed case, a bad query), plus a
WorkflowRuntimetest that reproduces the reportedDaprInternalErrorbefore the fix. Separately, I checked that grpc connects to a real server over a Unix socket using both targets the parser now produces.Issue reference
Please reference the issue this PR will close: #1213
Checklist