`core::0132::request-parent-required` false positive when the request message in a separate file

[CuriousStork]

Environment details

• OS: Windows
• Package version: api-linter 2.0.0

Steps to reproduce

1. Make sure core::0132::request-parent-required is enabled.
2. Create a List method for a top-level resource. Per https://protobuf.dev/best-practices/1-1-1/ use a separate .proto for the request message.

// `api/v1/test.proto` file
syntax = "proto3";

package api.v1;

import "google/api/annotations.proto";
import "google/api/client.proto";
import "google/api/field_behavior.proto";
import "google/api/resource.proto";

import "api/v1/list_items_request.proto";

service ItemApi {
  rpc ListItems(ListItemsRequest) returns (ListItemsResponse) {
    option (google.api.http) = {
      get : "/v1/items"
    };
    option (google.api.method_signature) = "";
  }
}

message Item {
  option (google.api.resource) = {
    type: "whatever.googleapis.com/Item"
    pattern: "items/{item}"
  };

  string name = 1 [(google.api.field_behavior) = IDENTIFIER];
}

message ListItemsResponse {
  repeated Item items = 1;

  string next_page_token = 2;
}

// `api/v1/list_items_request.proto` file
syntax = "proto3";

package api.v1;

import "google/api/field_behavior.proto";

message ListItemsRequest {
  int32 page_size = 1 [(google.api.field_behavior) = OPTIONAL];

  string page_token = 2 [(google.api.field_behavior) = OPTIONAL];
}

api.v1.ListItemsRequest is flagged with core::0132::request-parent-required, however, the api.v1.Item resource has no parent.

[noahdietz]

Hey @CuriousStork, happy new year!

I think the root cause of this is that rules are not operating with all of the files provided as input at their disposal. The rule is given its descriptor to lint and it can only access the contents of the descriptor's containing file and the files that the containing file imports.

When following proto 1-1-1, everything is fragmented and means that the API Linter cannot find types that would resolve the relationships it needs to know about i.e. which message is the resource and is it a top-level resource.

I've had an internal bug (http://b/379152432 for Googlers reading this) in the backlog for some time now. Proto 1-1-1 becoming a thing makes it more likely to happen, but I'm not sure we will be able to fix it soon.

[noahdietz]

@quirogas fyi I realized after triage that my initial interpretation was incorrect. See above ^

[noahdietz]

Random idea: Can we update the rule utilities looking for types by name to instead consult the process's global proto registry to find types by name? I wonder if our parsing of .proto files into Go descriptor types also registers them in the global proto registry. If not, we can make one and set it (as read only) after parsing the files.

[CuriousStork]

Hello @noahdietz,

Thanks for the wishes! Happy New Year to you too (a bit late, but sincere).

About your comment, I totally understand that finding all the importing files with List RPCs is not a trivial task.

Just a side note, I've tried manually passing the files, unfortunately the issue still reproduces:

api-linter --proto-path=third_party .\api\v1\list_items_request.proto .\api\v1\test.proto