@andreamlin, do you have any comments on this issue?

Ok, found the reason for the removal of those functions: these formatResourceName functions are generated when the resource_name_generation section of the GAPIC config is empty (gapic-generator implementation). Because vision_gapic.yaml did not have a resource_name_generation section at the last refresh of the vision client, the resulting client library DID contain these formatting functions. Between the last refresh and this one, vision_gapic.yaml was populated with a resource_name_generation section.

One possible solution is to always print out these formatting functions; however this adds a lot of cruft to every other Java API library.

Another possible solution is to mark these formatting functions as @BetaApi after the fact and mark them for turn down. We would expect that eventually, per API, all resource messages are configured and these formatting functions wouldn't be necessary.

cc'ing @michaelbausor. This behavior was introduced years ago, in googleapis/gapic-generator#824.

Hmm. Another option - we add an optional configuration into the resource_name_generation, and update the generator to check for it. So the methods will be generated either when the resource_name_generation section is missing, or when it is present with the config set. This will allow an API that doesn't have a resource_name_generation config to specify one in a non-breaking way. But, it adds configuration, which is not desirable.

Separate question - how do we expect the generator to behave when we move to the proto annotation config spec?

@michaelbausor
That seems like a workable solution. It is only a boolean flag, and only used for instances like this.

re: proto annotation spec; for new API client libs, we would never enableStringFormatFunctions unless there were no Resource Name configs, in which case it's an irrelevant point because there will be no resource name entities to format. However, if we remove the GAPIC config and move to proto annotations for existing APIs like Vision that still have the String format functions, then they will broken just like in this PR. In that case, we can introduce a command-line option to enableStringFormatFunctions that will purely be used for maintaining backward compatibility (or maybe keep a config param exposed in GAPIC config).

Opened gapic-generator issue to track this: googleapis/gapic-generator#2521.

@michaelbausor @chingor13 Would it be possible to deprecate these functions (if/when a major version comes around)? I'm not sure what the use of them would be given that they are are only present when there are no messages that reference them.

This should be fixed now, if synthtool is run again. My local regen: andreamlin#2