Should we set `require_unimplemented_servers=true` when generating gRPC-related code?

[SarahFrench]

Following #37685, when we compile Go gRPC code from our .proto files we use the require_unimplemented_servers=false option:

terraform/tools/protobuf-compile/protobuf-compile.go

Line 54 in ffbb62b

"--go-grpc_opt=require_unimplemented_servers=false",

This option is described in the documentation here: protoc-gen-go-grpc: Future-proofing services.

Setting require_unimplemented_servers=false is not recommended, but we are currently using it as it matches how our code was generated prior to #37685

However unimplemented server structs are currently being embedding in hashicorp/terraform despite it not being enforced:

• Use of packages.UnimplementedPackagesServer
• Use of dependencies.UnimplementedDependenciesServer
• Use of stacks.UnimplementedStacksServer

Similarly, hashicorp/terraform-plugin-go embeds unimplemented server structs: tfplugin5.UnimplementedProviderServer, tfplugin6.UnimplementedProviderServer

So maybe this shows we should set require_unimplemented_servers=true and make it consistent in this codebase?

References:

• Require Unimplemented services to be embedded in our canonical generated code packages? grpc/grpc-go#3674
• https://stackoverflow.com/questions/65079032/grpc-with-mustembedunimplemented-method

[jbardin]

Conceptually I think this sounds fine, and we'd have a full development cycle to test it out anyway. I'm pretty sure the current setup is only because that is what the defaults were when we first adopted grpc.

IIUC the only parts that would be directly affected are the stacks services, since the normal CLI workflow doesn't use any grpc servers itself.

[SarahFrench]

IIUC the only parts that would be directly affected are the stacks services, since the normal CLI workflow doesn't use any grpc servers itself.

That's true! In that case we should be ok to go ahead. I'll raise this in the team meeting briefly but seems like this is an uncontroversial change