-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compute/computepb: Missing *Server interfaces #11192
Comments
This was an intentional change as those generated bindings were published by mistake. compute is not a gRPC based service and should never have generated those types. How/why were you referencing this type? |
We are using this in test harnesses. The service definitions in the proto source contain I'm open to other suggestions for in-memory testing that let's us use REAL clients against fake backends (edit) without handwriting a bunch of REST mappings myself. example annotation from the
|
It looks like we need to update our testing.md in this repo for a good example of that, but the same strategy that is outlined in our older client libs should work here as well for compute: https://github.com/googleapis/google-api-go-client/blob/main/testing.md#testing-http-services-using-fakes |
Yes, that's the avenue of hand-crafting REST fakes. It is tedious and repetitive to get right, especially when all the mappings are already defined in the proto service. The example fake in the documentation has a single handler that does no input interpolation for proper faking. A more serious example for say the
That's a lot of unnecessary work to hand-write especially when the mappings are already in the service definition. And then there's 97 more services just like this in this one proto. Before this change, the gRPC interfaces were helping bridge this usability gap. Is there any downside to generating them? |
The main reasons we made these changes:
I am not familiar with the project you listed about to suggest a better workaround. We had considered this may be referenced in test code, but did not fully consider transcoding style use cases you have mentioned in this issue. |
Client
Compute
Environment
go version go1.23.9 linux/amd64
Code and Dependencies
go.mod
Expected behavior
I expect it to find the type and compile.
Actual behavior
It does not find the type.
main.go:5:11 undefined: computepb.NetworksServer
Additional context
If I checkout v1.28.2 of the package, everything works fine.
This commit: 706ecb2 removed all of the generated *Server interfaces from the
computepb
package, and code referencing these types no longer builds with the latest versions.Many of the interfaces were removed in this change:
The text was updated successfully, but these errors were encountered: