Validation problem w/ nested messages

[Chris Toomey]

In a project using scalapb-validate-codegen 0.2.2 and a scalapb-generated library of common message types that was NOT built with scalapb-validate-codegen, I'm seeing inconsistent behavior w.r.t. the generated validators attempting to do nested message validation.

For this message

message NestedValidate {

    google.protobuf.StringValue foo = 1;

    google.protobuf.Duration dur = 2;

    com.livongo.protobuf.common.types.Date date = 3;

}

the generated validator for NestedValidate attempts to use the non-existent validator for date -- but not for foo or dur --  and so doesn't compile. All 3 of those types are provided by the same scalapb-generated library dependency.

object NestedValidateValidator extends scalapb.validate.Validator[example.myapp.helloworld.grpc.NestedValidate] {

  def validate(input: example.myapp.helloworld.grpc.NestedValidate): scalapb.validate.Result =

    scalapb.validate.Result.optional(input.date) { _value =>

      com.livongo.protobuf.common.types.DateValidator.validate(_value)

    }

}

Per https://github.com/envoyproxy/protoc-gen-validate it should only attempt to use nested message validators if the nested message was also built with validation enabled, and none of those nested message types were.

Suggestions on what might be causing this and how to prevent?

thx,

Chris

[Nadav Samet]

Hi Chris,

I assume you meant referenced messages - not nested messages. Nested messages are messages that are defined inside another message. scalapb-vallidate-codegen has no way of telling whether there is or there is not a validator for a message, since a validator for a referenced message may or may not have been generated in a previous protoc run or in another project. It currently assumes everything your code references comes with a validator. It makes a special case for "google.protobuf.*" because that typically isn't generated by the user.

We could add some option to tell scalapb-validate-codegen that com.livongo.* doesn't have validators. Feel free to file a feature request on scalapb-validate on github. 

 

Per https://github.com/envoyproxy/protoc-gen-validate it should only attempt to use nested message validators if the nested message was also built with validation enabled, and none of those nested message types were.

Can you provide the exact reference for this? I couldn't find that on the link.

-Nadav

--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/21c7f296-512d-4af4-9dc2-46161ee2bf63n%40googlegroups.com.

--

-Nadav

[Chris Toomey]

Here's where it talks about validating referenced messages: https://github.com/envoyproxy/protoc-gen-validate#messages .

For java they use reflection to find the validator for a given message type, and if none is found, use a default no-op / success validator:

• 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
  

I just filed https://github.com/scalapb/ScalaPB/issues/1116 for this.

For now we can just rebuild the common-types library with validation enabled to work around this.

Chris