Closed lwmxiaobei closed 3 years ago
This would be a bug in your implementation of server reflection.
When downloading descriptors, grpcurl
basically does the following:
file_containing_symbol
request for the given service name.file_by_filename
request with the resulting filename. After unmarshaling the returned google.protobuf.FileDescriptorProto
, it makes more requests for each dependency, recursively, until the entire transitive dependency graph has been downloaded.google.protouf.Timestamp
in all of the downloaded file descriptors.The issue is either in the file descriptor returned for the main file, gd_pts_afterSale.proto
, such that it does not correctly include all of its dependencies, OR there is a problem in the file descriptor returned for google/protobuf/timestamp.proto
, such that it does not correctly define this type (perhaps an issue with the declared package of the file or missing declarations?).
thinks. I loaded proto through proto-loader. google/protobuf/timestamp.proto is provided by Google, will it automatically load dependencies? My server is implemented through proto-loader, and grpcurl -proto can work normally. The following is the FileDescriptorProto I loaded through the proto-loader. I am not sure whether the dependency is included. How can I confirm whether the dependency is included?
The first element of the fileDescriptorProtos array is gd_pts_afterSale.proto, and the second element is google_protobuf.proto. It seems that all dependencies are returned to grpcurl, but I’m not sure if I need to deal with anything else.
I found the problem, need to use FileDescriptorProto.addDependency('google_protobuf.proto') to add a dependency, so that it can work
Because grpc-js does not support reflection, so I implemented server-side reflection myself, but when I used google.protobuf.Timestamp in proto, I got an error. Here is a screenshot:
but when I remove google.protobuf.Timestamp it is normal I don't know why this is,can you help me ? thinks
This is part of my proto file content: