[Feature Request] ignore `compilation error: no evaluator available for` option about protovalidate HOT 5 CLOSED

Hey @derekperkins, thanks for raising the issue - I have a couple of assumptions about your set up that i would like you to confirm to deny.

1. You are prewarming messages into the validator at construction
2. You have lazy loading disabled
3. You are sending messages which:
   - have been presented at construction but;
   - do not have validate extensions yet

Is this correct?

from protovalidate.

Yes to 1 and 2. For 3, no messages have validate extensions yet, this is the initial PoC. We have two separate proto paradigms, for pre and post-Buf. All our new development happens in a single buf module shared in a monorepo, but the old protos are scattered and don't belong to the module, and thus can't be referenced by buf. We're currently generating all the new messages into the WithMessages call, but can't really do that (nor want to) for the older proto messages. This is basically what's happening now, where we create a new server with the buf module code, then register the old server in the same place.

// codegen for all buf module services
s := workspacesv1.NewServer(c, v1App)

// register pre-buf grpc server
workspacespb.RegisterWorkspacesAPIServer(s, app)

// code gen server func
func NewServer(c context.Context, app Server) *grpc.Server {
	v, err := protovalidate.New(
		protovalidate.WithDisableLazy(true),
		protovalidate.WithUTC(true),
		protovalidate.WithMessages(
			&ListModelsRequest{},
			&ListModelsResponse{},
			// ...
		),
	)
}

That's all very specific to us, but I imagine that most users migrating to protovalidate are going to do it incrementally. I get that the Lazy default is built for this, I'm just hoping for a middle ground between registering everything at compile time and paying a performance penalty on every single request. If it's not registered, that's fine, just don't error.

from protovalidate.

I just wanted to shed some light on the lazy loading functionality of the protovalidate library:

1. When lazy loading is enabled, the validator constructs validation logic only when it first encounters a particular message type. If a message type doesn't have validation rules defined, it essentially becomes a no-op for that message type. This is in contrast to the behavior when lazy loading is disabled, where the library expects to be aware of all message types it will be asked to validate at construction time. If it encounters an unfamiliar message type in this mode, it throws an error, as noted in the comments here.

2. Regarding the performance hit for enabling lazy loading, according to the Performance section in the protovalidate library's documentation, the overhead is sub-microsecond. In practical terms, this is a very minor delay compared to the overall latency of a typical gRPC request. The gRPC layer itself tends to have orders of magnitude more overhead.

So, considering your specific use case – an incremental migration towards protovalidate – enabling lazy loading might actually be a reasonable compromise. It should allow you to smoothly transition without needing to have all your old and new proto messages registered upfront, and without the need to modify the library to introduce a new option for ignoring compilation errors.

Given this, would you consider giving lazy loading another shot? It might turn out to be a surprisingly good fit for your incremental adoption scenario, without a noticeable performance penalty.

from protovalidate.

Hi @derekperkins, just checking in on this issue. Please let us know if you're still facing the problem, or if there's any additional information you can provide to assist us. Thanks!

from protovalidate.

It hurts me to incur that per request for not much value, but is the right choice for this library. Thanks for your feedback

from protovalidate.