fmt.Sprintf call has arguments but no formatting directives

[codyoss]

This error has been observed when trying to generate REGAPICS. There were a handful of libraries that were manually excluded from the initial beta/alpha generation of REGAPICS due to this error and now it seems some more are starting to have it. In googleapis/google-cloud-go#6269 It was observed in both security/privateca and gaming:

# cloud.google.com/go/security/privateca/apiv1beta1
privateca/apiv1beta1/certificate_authority_client.go:1968:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2040:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2103:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2166:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2434:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2497:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2571:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2791:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:2961:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3043:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3125:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3207:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3289:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3371:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3453:25: fmt.Sprintf call has arguments but no formatting directives
privateca/apiv1beta1/certificate_authority_client.go:3535:25: fmt.Sprintf call has arguments but no formatting directives

Code: https://github.com/googleapis/google-cloud-go/pull/6269/files#r909626615

[noahdietz]

The source of the issue is that the HTTP binding(s) for google.longrunning.Operations.GetOperation (in this case) isn't included in the service yaml for both APIs. Their service configs haven't been updated since mid 2020. I will send change to those files to publish just those bindings.

We could do more in the generator to fail, but I wonder what Java is doing when there is no GetOperation http rule in the serviec yaml. @vam-google can you answer that?

[noahdietz]

I have two changes open to add the missing http bindings for LROs.

[vam-google]

@noahdietz java does not read those values, but instead constructs the url path based on the version of the package the LRO logic is being imported from. Luckily enough all the LRO url paths follow the same general pattern (excluding the name pattern, but that does not get validated), so this works. BAsically a hack, but is simple and does the job.

[noahdietz]

Perhaps the Go generator should do the same as a fall back in the event that the http binding isn't present...

[noahdietz]

So I the two APIs in question had their configs fixed, which means we can attempt to generate them with REGAPIC again.

Since this wasn't actually a bug in the generator, I am going to change this to type: feature request scoped to adding "fall back" support for missing http binding.

[noahdietz]

Perhaps the Go generator should do the same as a fall back in the event that the http binding isn't present...

@quartzmo another good item to pick up if you are interested, no pressure though. We can pair at some point if you'd like.

[codyoss]

Note, I still do believe there are more of these, but I lack my notes to know which clients. I skipped generating some APIs in the first batch due to this error. So a fix/feat will still be needed for wider rollout.