Don't attempt to validate referenced message types without validators

[ctoomey]

Per https://github.com/envoyproxy/protoc-gen-validate#messages

If a field contains a message and the message has been generated with PGV, validation will be performed recursively. Message's not generated with PGV are skipped.

However ScalaPB's generated message validators assume all message types other than google.protobuf.* have validators and thus fails to compile when referencing message types without validators.

E.g. when using scalapb-validate-codegen and compiling this message

message Outer {
    com.example.types.Foo foo = 1;
}

it will generate a validator like

object OuterValidator extends scalapb.validate.Validator[Outer] {
  def validate(input: Outer): scalapb.validate.Result =
    scalapb.validate.Result.optional(input.foo) { _value =>
      com.example.types.FooValidator.validate(_value)
    }
}

To avoid this problem, PGV's java implementation uses reflection to find message validators (caching result after first time) and uses a fallback always-valid validator for message types without validators:

• https://github.com/envoyproxy/protoc-gen-validate/blob/main/java/pgv-java-stub/src/main/java/io/envoyproxy/pgv/ReflectiveValidatorIndex.java
• https://github.com/envoyproxy/protoc-gen-validate/blob/main/java/pgv-java-stub/src/main/java/io/envoyproxy/pgv/ValidatorIndex.java

[thesamet]

Thanks for reporting. I would prefer that we do it in scalapb-validate via configuration (versus reflection). A new config option will let the user specify which packages to not assume there's a validator for, to make sure that what gets validated is determined at compile time and not at runtime.

[ctoomey]

Are you mainly concerned about the runtime cost of the first-time lookups per message type, or do you have other concerns about using reflection?

[thesamet]

• compile time certainty that validation is included. It looks like in PGV's solution validation is silently skipped at runtime if classes are not found.
• have a forward path to support non-jvm platforms