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
Existing open issues along with etcd frequently asked questions have been checked and this is not a duplicate.
What happened?
If you send a request for the watch method to the grpc-proxy, you can get the connection closed immediately through the grpcurl utility. But if you send the same request to the etcd server, the events will come. The difference is that the etc server has EOF processing, while the grpc proxy does not
What did you expect to happen?
The grpc proxy should not close the stream, but send events by key
How can we reproduce it (as minimally and precisely as possible)?
A request that will not keep the stream open with the grpc proxy (it will immediately close the stream) and will work correctly with the etcd server
request=$(echo {\"create_request\": {\"key\": \"test-key\", \"range_end\": \"test-key-end\"}})
grpcurl \
-d "@" \
-import-path $proto_path -proto "etcdserver/etcdserverpb/rpc.proto" \
127.0.0.1:12379\
"etcdserverpb.Watch.Watch"<<EOF$requestEOF### Anything else we need to know?
The etcd server [has EOF processing](https://github.com/etcd-io/etcd/blob/release-3.4/etcdserver/api/v3rpc/watch.go#L252)
At the same time,[ grpc-proxy does not have it](https://github.com/etcd-io/etcd/blob/release-3.4/proxy/grpcproxy/watch.go#L226)
### Etcd version (please run commands below)<details>```console$ etcd Version: 3.4.28Git SHA: Not provided (use ./build instead of go build)Go Version: go1.22.0Go OS/Arch: darwin/arm64$ etcdctl version: 3.4.19API version: 3.4
Etcd configuration (command line flags or environment variables)
default
Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered:
Bug report criteria
What happened?
If you send a request for the watch method to the grpc-proxy, you can get the connection closed immediately through the grpcurl utility. But if you send the same request to the etcd server, the events will come. The difference is that the etc server has EOF processing, while the grpc proxy does not
What did you expect to happen?
The grpc proxy should not close the stream, but send events by key
How can we reproduce it (as minimally and precisely as possible)?
A request that will not keep the stream open with the grpc proxy (it will immediately close the stream) and will work correctly with the etcd server
Etcd configuration (command line flags or environment variables)
default
Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: