v1.1.1

Bug Fixes

• The protoc-gen-grpchan plugin could not be used with proto source files that used the recent "proto3 optional" feature. The actual plugin code would function perfectly fine in the face of such sources. But the protocol that protoc uses to determine if a plugin is compatible or not was not properly implemented by protoc-gen-grpchan. This has been fixed: the plugin can now be used on such source files.

v1.1.0

It's been a while since an official numbered version of this was released, so there are lots of updates and improvements.

Compatibility Note

This repo was updated to generate code compatible with the newer gRPC and protobuf runtimes as well as newer protoc plugins: protoc-gen-go (from google.golang.org/protobuf) and protoc-gen-go-grpc (from google.golang.org/grpc).

To continue targeting these older runtimes, you will need to pass options to the protoc-gen-grpchan plugin or else the generated code will not be compatible. Also note that as of v1.36.0 of google.golang.org/grpc, this plugin is no longer necessary at all. The latest gRPC runtime and protoc plugin generate code that references interfaces for both client-side stubs and server-side handler registration, instead of concrete types.

API Additions

• Added inprocgrpc.ClientContext: given a server-handler context for an in-process RPC, this returns the original context that was provided to the client stub. It returns nil if the given context is not from an in-process RPC. This can be useful for testing and for interceptors.
• Added a new ErrorRenderer type to the httpgrpc package and options for configuring a custom renderer with the HandleMethod, HandleStream, and HandleServices functions.

Improvements

• Added import_path and M options to the protoc-gen-grpchan plugin, so that it can now be configured using the same options as protoc-gen-go for determining the Go package for protobuf source files.
• Added module and paths options for the protoc-gen-grpchan plugin, so that it can now be configured using the same options as protoc-gen-go for determining output paths of generated files.
• Both httpgrpc and inprocgrpc packages can use a codec registered with gRPC (in the google.golang.org/grpc/encoding package) for the "proto" encoding type. The inprocgrpc package will use this if the message cannot be cloned without serialization (such as if the message does not implement the expected interface).
• The httpgrpc package supports "application/json" as the content type for unary RPCs. It will use the "json" codec registered with gRPC for marshaling and unmarshaling.
• The generated code has been updated to be compatible with v1.36.0 of the gRPC runtime. The resulting generated code is not source compatible with previous code versions of v1.36.0. If you need to generate code and remain compatibility with earlier versions of the gRPC runtime, you can use new options to the protoc-gen-grpchan plugin:
  • legacy_desc_names: This option will generated references to service descriptors using the older, unexported name (pre-v1.36.0). This option is required when using versions prior to v1.36.0 of the gRPC runtime.
  • legacy_stubs: This option will generate the factory functions for creating stubs from a grpchan.Channel. This is for targeting very old versions of the gRPC runtime that do not define the grpc.ClientConnInterface type.

Bug Fixes

• For in-process RPC, the server is not allowed to return a nil response message and a nil error; one or the other must be supplied. If both are nil, the client will receive an "Internal" error. This now correctly matches the behavior of out-of-process RPC. Previously, in-process RPCs would incorrectly accept a nil response and assume an empty response message and no error instead.
• In the httpgrpc package, if a client stream were abandoned, without cancelling a parent context for the stream, some resources would never get cleaned up. This resource leak has been addressed via the use of a finalizer.
• Fixed a bug in the ProtoCloner, used in inprocgrpc by default, which could result in a type assertion panic if something other than a proto.Message were used.
• If an attempt was made to call InterceptClientConn or InterceptChannel on a channel that was already decorated with interceptors via a call to one of these two functions, an infinite loop would occur and deadlock the calling goroutine. This has been fixed.

v1.0.1

This fixes an issue in the go.mod file that would prevent earlier versions from working with modules when using Go 1.13.

v1.0.0

This repo is sufficiently mature and used in enough production systems that a "1.0" release is overdue.