Make it so that you can define expression-only rules#288
Merged
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / validate-protos (pull_request).
|
This was referenced Nov 8, 2025
emcfarlane
approved these changes
Nov 25, 2025
This was referenced Nov 28, 2025
srikrsna-buf
added a commit
to bufbuild/protovalidate-java
that referenced
this pull request
Dec 2, 2025
Same as bufbuild/protovalidate-go#288 Signed-off-by: Sri Krishna <skrishna@buf.build>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This has been a constant annoyance of mine whenever using Protovalidate that I'd like to clean up in every language. It should be easy in other languages, this is just for Go.
Whenever I define a CEL rule, I am constantly annoyed that I have to define an
idand amessagewhen the expression contains all the context I need. I want to be able to do this:Instead, I'm all but forced to do this:
I don't understand why I have to come up with a unique ID, and why I have to pay the mental overhead of coming up with a human-readable message when all the context I need is right in the expression.
Right now, if I don't set a message or ID, I'll get a
Violation, but theStringof the violation is[]. This PR fixes that to default to returning the expression, and the error message is now exactly what I want:Corollary, but both out of scope in this PR and not perfectly unfixable without a breaking change (although we can make improvements):
It's super annoying to me that
(buf.validate.field).celisn't CEL. It's a message that then has a fieldexpressionthat is CEL. All I actually want to do is this:As a next-best, I'd want to do this:
But this is a Protobuf compile error because
(buf.validate.message).celis a repeated message.In hindsight, I wish we did:
And then I could do the full version with
(buf.validate.message).ruleand the simple version with(buf.validate.message).cel, which also matches what I'd expect (ruleis aRule,celis a CEL expression). But we can't do that anymore.Perhaps we could do:
Then I could do:
But that is for a future PR. For now, I just want this to work without
idormessage.