Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update for editions #174

Merged
merged 7 commits into from
Aug 5, 2024
Merged

Update for editions #174

merged 7 commits into from
Aug 5, 2024

Conversation

jchadwick-buf
Copy link
Member

@jchadwick-buf jchadwick-buf commented Jul 26, 2024

Updates protovalidate, adds support for new ignore semantics. The PR is huge but it's mostly gencode; the actual CEL code wasn't too substantially altered.

Unfortunately I could not get the tests to pass 100%. There is a minor wrinkle where, I believe, the behavior of has(x.y) and x.y needs to differ (specifically with proto3 optional) but it can not due to the way the interpreter works. It seems like this only impacts some rather small edge cases so I guess we might be able to live with it in the interim. I've just added said tests to the nonconforming list. Update: The issues still exist upstream (assuming the issue is valid and not a mistake on my part) but we are now working around it, and tests now pass 100% (sans the existing failures.)

All other tests pass and I believe my fixes are correct. The e-mail check was corrected to not support bracketed emails as was done with the Go version.

tests/conformance/nonconforming.yaml Outdated Show resolved Hide resolved
Python is not particularly fast. The new test suites seem to run close
to the timeout on GitHub actions, especially on older, slower Python
versions, so let's increase the timeout a bit.

While the Python protovalidate implementation could be faster, this is
probably also reflective of GitHub Actions being somewhat slow, too.
Right now, it seems like it is not possible to implement field presence
100% accurately for protobuf types when using cel python, as the result
of the `has` macro is tied to whether or not the expression in it can be
evaluated. This fails in the protobuf case because `has` should be false
in some cases even when a default value will be returned.

This is a somewhat ugly workaround that patches the interpreter so we
can track when we are inside of a `has` macro call and cause there to be
an evaluation error if the field is unset.
@jchadwick-buf
Copy link
Member Author

OK, I think all outstanding issues should be resolved. I don't think we're in a rush to close this though so I'll leave some time for people to respond before merging this.

@jchadwick-buf jchadwick-buf merged commit 4c035d0 into bufbuild:main Aug 5, 2024
12 checks passed
@jchadwick-buf jchadwick-buf deleted the editions-update branch August 5, 2024 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants