Phase 1 to add the server interceptor

[iamqizhao]

No description provided.

[dsymonds]

The golang/protobuf change has been pushed: golang/protobuf@331aba2

[spenczar]

This backwards-incompatible change broke builds for teammates and produced confusing errors. I can't find any explanation for the changes, nor can I see anything in the milestones which would have helped see that this was coming up. Is there anywhere I can subscribe to announcements of these kinds of breaking changes?

[zellyn]

@spenczar there are version checks in both grpc-go and go-protobuf specifically to ensure that the versions match. If you upgrade one, upgrade the other too.

[iamqizhao]

Sorry for the breakage. This breaks only if you cache and use the generated code directly. Otherwise, it should be transparent to users. Anyways, I am going to pay more attention on this and will announce any potential breaking changes on a github issue. You do not need to subscribe anywhere else.

[riannucci]

Drive-by/Quick question: Why do the handler methods/types take interface{} instead of proto.Message?

[iamqizhao]

@riannucci It is because gRPC and protobuf are not a bundle. Users are allowed to use other things as their IDLs. But all the IDLs need to share this same API -- this interface{} could be a proto.Message or a slice or something else.

[nodirt]

Why code generation had to be changed? The interceptor in the generated code seems to be unnecessary because handler func doesn't pass any data to the interceptor that the caller of the handler func doesn't already have. Note that in is passed to dec

[iamqizhao]

For the streaming rpc interceptor (which I am working on) the codegen is not changed. For unary rpc, we have to do that because protobuf decoding happens in the generated code. The interceptor impl needs to call handler(ctx, in) by itself to complete the rpc as usual if they want. We will have a doc to describe the design and show some examples.

[nodirt]

Yeah, I see. I just tried to write a patch for (*Server).processUnaryRPC and got stuck on the fact that the handler that interceptor receives is a func that accepts a decoded messages whereas generated handler receives a func that does decoding, not a decoded message.

[thelinuxfoundation]

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.

After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

• User @iamqizhao isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot