-
Notifications
You must be signed in to change notification settings - Fork 51
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
fix(internal/gengapic): add workaround for operation collision #1397
Conversation
We have a service that is not yet released that uses the same RPC name across two services in the same proto package. Our Operation wrapper identifiers are not scoped to a service so this causes issues when generated a client that does this. For now this is for one client, which may change before GA, so a hacky solution is fine. But we should keep this in the back of our minds should we ever v2 our libraries this is something we would want to avoid.
if eHTTP, ok := proto.GetExtension(m.GetOptions(), annotations.E_Http).(*annotations.HttpRule); ok && eHTTP != nil && eHTTP.Pattern != nil { | ||
switch t := eHTTP.Pattern.(type) { | ||
case *annotations.HttpRule_Post: | ||
if t.Post == "/v1beta1/{parent=projects/*/locations/*/featureGroups/*}/features" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems at least a tiny bit possible that someday another RPC will match this pattern...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may, but I believe it is unlikely. Ideally this code gets deleted in the next couple of months. If we end up having to do this for the v1 service we can make the logic tighter at that time. I was trying to avoid passing a lot more info throughout the stack if possible so this is easy to unwind.
We have a service that is not yet released that uses the same RPC name across two services in the same proto package. Our Operation wrapper identifiers are not scoped to a service so this causes issues when generated a client that does this. For now this is for one client, which may change before GA, so a hacky solution is fine. But we should keep this in the back of our minds should we ever v2 our libraries this is something we would want to avoid.