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
When a gRPC service is defined in a proto a corresponding interface is generated. A user is expected to implement this interface.
When the proto is updated to add a new API method, the interface generated changes.
Any struct that implements that interface is no longer in conformance. Therefore, the code breaks.
I would expect the structs to be forward compatible.
This can potentially be solved by the code generating a dummy struct that implements the interface. Users can then embed that struct and only implement the methods they care about, effectively overriding the default methods.
Solution proposed by : @dfawley@dsymonds
The solution inside Google is that the stubby codegen creates an UnimplementedFooService concrete type that implements the interface with methods that return an unimplemented error. Servers that wish to avoid breaking when the Foo service is extended can embed that type in their own implementation, and new methods will thus transparently work (by returning that unimplemented error). That's effectively what the OP suggests, and it seems to work well enough in practice.
The text was updated successfully, but these errors were encountered:
prannayk
changed the title
Feature request: Provide a way to make sure that their code does not break when services add new rpcs.
Feature request: Provide a way to make sure that code does not break when services add new rpcs.
Jan 15, 2019
prannayk
changed the title
Feature request: Provide a way to make sure that code does not break when services add new rpcs.
Feature Request: Ensure that code does not break when services add new RPCs.
Jan 15, 2019
Imported from: grpc/grpc-go#2318 as-is.
When a gRPC service is defined in a proto a corresponding interface is generated. A user is expected to implement this interface.
When the proto is updated to add a new API method, the interface generated changes.
Any struct that implements that interface is no longer in conformance. Therefore, the code breaks.
I would expect the structs to be forward compatible.
This can potentially be solved by the code generating a dummy struct that implements the interface. Users can then embed that struct and only implement the methods they care about, effectively overriding the default methods.
Solution proposed by : @dfawley @dsymonds
The solution inside Google is that the stubby codegen creates an UnimplementedFooService concrete type that implements the interface with methods that return an unimplemented error. Servers that wish to avoid breaking when the Foo service is extended can embed that type in their own implementation, and new methods will thus transparently work (by returning that unimplemented error). That's effectively what the OP suggests, and it seems to work well enough in practice.
The text was updated successfully, but these errors were encountered: