Repository navigation
rules 132 and 133 check for a non-existent field #112
Description
Rules 132 and 133 check for the child_type field on resource_reference [1], but AEP specifies the resource reference as a string [2]. These two conflict, since the string type can't have a child_type field. Either the checks need to be disabled or the resource reference type needs to be changed to a message here: https://github.com/aep-dev/aep-components/blob/main/proto/aep-api/aep/api/field_info.proto.
Notably, AEP differs from Google's proto definitions here, as Google defines a ResourceReference as its own type, with type and child_type fields [3]. I think this is probably a better direction, but will defer to maintainers on what to do here.
Reacted by Andrew Womeldorf
Metadata
Metadata
Assignees
Labels
No labels
Activity
[-]rule 132 checks for a non-existent field[/-][+]rules 132 and 133 check for a non-existent field[/+]andrew-womeldorf commentedon Oct 27, 2025
I started getting the same error after upgrading my linter today. I believe this is a result of the work done in #111 .
toumorokoshi commentedon Nov 1, 2025
Thanks for the report!
Yes, we missed adding
child type. And I think we probably still need to add it (as in some cases it might be valuable to express a child type).The primary motivation to switch it from an object to a top-level field is because we are aggregating field-level annotations into
field_info- since resource references are a common use case, the need to have effectively a three-level deep annotation as a common use case felt clunky:string resource = 2 [(aep.api.field_info) = { resource_reference: { type: "api.example.com/user" } }];I think we could just add a sibling field alongside it for child references, however:
string resource = 2 [(aep.api.field_info) = { resource_reference_child_type: "api.example.com/user" }];thoughts?
toumorokoshi commentedon Nov 1, 2025
@rambleraptor assigning to you for either disabling or fixing the rule for now.
feat: add resource_reference_child_type (#38)