Skip to content

gapic-generator-java: LRO parsing can match wrong response or metadata type  #1707

@emmileaf

Description

@emmileaf

This issue happens in Parser.parseLro(): if only shortname is provided, and has ambiguity with message types from other protos, the parser currently naively matches on first encountered type, without throwing exception or indicating conflict.

// The messageTypes map keys to the Java fully-qualified name.
for (Map.Entry<String, Message> messageEntry : messageTypes.entrySet()) {
String messageKey = messageEntry.getKey();
int messageLastDotIndex = messageEntry.getKey().lastIndexOf('.');
String messageShortName =
messageLastDotIndex >= 0 ? messageKey.substring(messageLastDotIndex + 1) : messageKey;
if (responseMessage == null) {
if (isResponseTypeNameShortOnly && responseTypeName.equals(messageShortName)) {
responseMessage = messageEntry.getValue();

Example proto to reproduce:

  • Annotation type is ambiguous with DescriptorProtos.GeneratedCodeInfo.Annotation
  • Location type is ambiguous with DescriptorProtos.SourceCodeInfo.Location
service TestService {
 ...
  rpc annotationTest(Request) returns (google.longrunning.Operation) {
    option (google.longrunning.operation_info) = {
      response_type: "Annotation" 
      metadata_type: "Location"
    };
  }
}

message Annotation {
  string name = 1;
}

message Location {
  string name = 1;
}

Metadata

Metadata

Assignees

Labels

priority: p2Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions