Increase plugin grpc message size to 64mb

[gavinbunney]

This increase the plugin server grpc messages size to reflect the same values as the client (hashicorp/terraform#20879).

Without this change, grpc will fail sending messages of larger than 4mb, regardless of the client setting already done in Terraform:

rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5655893 vs. 4194304)

[paultyng]

This should only be set for the GetSchema call as its done in the client. Not sure if there is some way to do that on the server in gRPC?

[gavinbunney]

@paultyng AFAICT it's only available on the entire server as it impacts the channel itself, so individual proto handling can't be changed

[paultyng]

It looks like the default for send is already math.MaxInt32: https://pkg.go.dev/google.golang.org/grpc#MaxSendMsgSize

The only place the Terraform CLI client overrides the 4mb limit is the receive for GetSchema, so I think this is already possible given the default send. All the rest of the client requests use the 4mb limit.

[paultyng]

I believe this is the only override in the CLI: https://github.com/hashicorp/terraform/blob/0c0ea09546d565daeca9c291d545aff5884824f6/plugin/grpc_provider.go#L136

[gavinbunney]

Thanks @paultyng, you're right that the default for send is MaxInt32, however receive is still 4mb. I'm not familiar with the internals of how the terraform <-> provider grpc integration works, in terms of what goes back and forth for the various GetSchema calls.

I've tested this fix in my provider here, without it, in the case of large kubernetes CRDs the grpc message size failure message appears (as reported by users here gavinbunney/terraform-provider-kubectl#59).

Happy to update this PR to only have the change for receive?

[paultyng]

If non-GetSchema calls with core are going over 4mb, I think that may actually be a bug/oversight on core's part that could be corrected in a future version (cc @jbardin if you have any additional context on this), so making this change here may turn breaking if they "fix the glitch" as it were. Considering this is affected by a string value, its not the GetSchema call but something else in the protocol going over 4mb, so fixing this, while it may work, may eventually just break again.

That being said, I'm not opposed to a more generic hook for you to override gRPC options.

Also, unsure if you are aware, but we've recently releases a lower level SDK (terraform-plugin-go) that allows usage of the "any" type for attributes. Which means instead of sending raw YAML, you could yamldecode this to a structured object, which would eliminate a lot of this size I would imagine, since it would strip whitespace, comments, etc. The Kubernetes Alpha provider among others is moving to this SDK to support the dynamic typing for those kinds of cases, its of course not a simple fix for you, but possibly something to consider longer term perhaps.

[paultyng]

Another thought I had was having a user roundtrip via the yamlencode/yamldecode to strip comments / whitespace, etc. (or doing this internally in your provider). Doesn't necessarily solve it indefinitely but maybe buys you some time?

[bflad]

Hi @gavinbunney 👋 Thank you for submitting this. The plugin package's underlying gRPC server implementation is being switched over to the terraform-plugin-go tfprotov5/tf5server package in #857 so all the SDKs are consistently implemented. As part of that migration, the gRPC message limit will be 256MB. Hope this helps and thanks again for the contribution.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.