[X] 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
$request
EOF
### 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.28
Git SHA: Not provided (use ./build instead of go build)
Go Version: go1.22.0
Go OS/Arch: darwin/arm64
$ etcdctl version: 3.4.19
API 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)
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)
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