You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS: Ubuntu (did not test others)
Python version: Python 3.9+
Package version: 0.44b0+ grpc version: <=1.50.0
What happened?
When using the gRPC instrumentation with a server that is exposed over a unix socket, we get the following error:
ValueError: not enough values to unpack (expected 2, got 1)
This seems to be because the context.peer() name is "unix://path/to/socket.sock", not simply "unix:". The instrumentation thinks that it is a host:port address and fails to parse it properly.
Note that the grpc project has at times tried to improve the communication of the socket path: grpc/grpc#18556. It seems that this changed after version 1.50.0 (versions 1.51 and 1.52 were yanked for other issues, 1.53.0 is the first version that does not have this problem.) However, I think that we should be handling the case when there is a path defined, as it seems like that's more correct.
uv run python -m grpc_tools.protoc -I./proto --python_out=./src --grpc_python_out=./src ./proto/helloworld.proto
uv run python src/server.py
(in another terminal) uv run python src/client.py
Expected Result
gRPC call should return without error.
Actual Result
Traceback (most recent call last):
File "/home/jason.anderson/workspaces/grpc-unix-socket-server/src/client.py", line 13, in <module>
run()
File "/home/jason.anderson/workspaces/grpc-unix-socket-server/src/client.py", line 10, in run
stub.SayHello(helloworld_pb2.HelloRequest(name="world"))
File "/home/jason.anderson/workspaces/grpc-unix-socket-server/.venv/lib/python3.11/site-packages/grpc/_channel.py", line 946, in __call__
return _end_unary_response_blocking(state, call, False, None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jason.anderson/workspaces/grpc-unix-socket-server/.venv/lib/python3.11/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNKNOWN
details = "Exception calling application: not enough values to unpack (expected 2, got 1)"
debug_error_string = "UNKNOWN:Error received from peer unix:/tmp/grpc.sock {grpc_message:"Exception calling application: not enough values to unpack (expected 2, got 1)", grpc_status:2, created_time:"2025-03-28T13:48:37.018497876-07:00"}"
Additional context
No response
Would you like to implement a fix?
Yes
The text was updated successfully, but these errors were encountered:
with some grpc implementations the full .peer address is available
for unix sockets, which includes the socket path. it seems that
in versions of grpc prior to 1.53.0, the full path is returned by
`context.peer()`. rather than change the dependency of the instrumentation,
this updates it to more gracefully handle the case of the socket path
being present or absent.
Fixesopen-telemetry#3393
* fix: grpc server ValueError when using unix sockets
with some grpc implementations the full .peer address is available
for unix sockets, which includes the socket path. it seems that
in versions of grpc prior to 1.53.0, the full path is returned by
`context.peer()`. rather than change the dependency of the instrumentation,
this updates it to more gracefully handle the case of the socket path
being present or absent.
Fixes#3393
* add changelog entry
---------
Co-authored-by: Riccardo Magliocchetti <[email protected]>
Describe your environment
OS: Ubuntu (did not test others)
Python version: Python 3.9+
Package version: 0.44b0+
grpc
version: <=1.50.0What happened?
When using the gRPC instrumentation with a server that is exposed over a unix socket, we get the following error:
This seems to be because the
context.peer()
name is "unix://path/to/socket.sock", not simply "unix:". The instrumentation thinks that it is a host:port address and fails to parse it properly.Note that the grpc project has at times tried to improve the communication of the socket path: grpc/grpc#18556. It seems that this changed after version 1.50.0 (versions 1.51 and 1.52 were yanked for other issues, 1.53.0 is the first version that does not have this problem.) However, I think that we should be handling the case when there is a path defined, as it seems like that's more correct.
Steps to Reproduce
requirements.txt
proto/helloworld.proto
src/server.py
src/client.py
How to reproduce:
uv venv --seed
uv run pip install -r requirements.txt
uv run python -m grpc_tools.protoc -I./proto --python_out=./src --grpc_python_out=./src ./proto/helloworld.proto
uv run python src/server.py
uv run python src/client.py
Expected Result
gRPC call should return without error.
Actual Result
Additional context
No response
Would you like to implement a fix?
Yes
The text was updated successfully, but these errors were encountered: