Conversation
Summary of ChangesHello @shivaspeaks, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces CEL-based matching capabilities to gRPC's xDS implementation, enabling more sophisticated traffic routing and management. It includes new classes for CEL compilation, evaluation, and string extraction, along with enhancements to existing string matching logic. The changes also incorporate necessary dependency updates and code reorganization to support the new functionality. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces the xDS Unified Matcher and CEL integration, aligning with gRFC 106. The implementation provides a flexible and powerful mechanism for request matching using CEL expressions and various input types. The code is well-structured, includes necessary dependency updates, and incorporates important features like recursion depth checks and keepMatching semantics. The accompanying test cases demonstrate good coverage of the new functionality.
xds/src/test/java/io/grpc/xds/internal/matcher/CelStringExtractorTest.java
Show resolved
Hide resolved
d493aa6 to
3bc58f7
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a new xDS matching framework with support for Common Expression Language (CEL) based matching and string extraction. Key changes include adding cel-runtime and cel-compiler dependencies, new classes like CelMatcher, CelStringExtractor, GrpcCelEnvironment, HeadersWrapper, and a hierarchy of UnifiedMatcher components (MatcherList, MatcherTree, PredicateEvaluator, OnMatch, MatchResult, MatchInput). The MatcherParser and Matchers classes were updated to support an ignoreCase option for string contains matching. Build configurations were adjusted for CEL dependencies and shading. Review comments noted significant code duplication between CelMatcher and CelStringExtractor that should be refactored into a shared helper, and a typo in the OnMatch class where isSpecifed should be isSpecified.
| public final class CelMatcher { | ||
|
|
||
| private static final CelOptions CEL_OPTIONS = CelOptions.newBuilder() | ||
| .enableComprehension(false) | ||
| .enableStringConversion(false) | ||
| .enableStringConcatenation(false) | ||
| .enableListConcatenation(false) | ||
| .maxRegexProgramSize(100) | ||
| .build(); | ||
|
|
||
| private static final CelCompiler COMPILER = CelCompilerFactory.standardCelCompilerBuilder() | ||
| .addVar("request", SimpleType.DYN) | ||
| .setOptions(CEL_OPTIONS) | ||
| .build(); | ||
|
|
||
| private static final CelRuntime RUNTIME = CelRuntimeFactory.standardCelRuntimeBuilder() | ||
| .setOptions(CEL_OPTIONS) | ||
| .build(); | ||
|
|
||
| private final CelRuntime.Program program; | ||
|
|
||
| private CelMatcher(CelRuntime.Program program) { | ||
| this.program = program; | ||
| } | ||
|
|
||
| /** | ||
| * Compiles the AST into a CelMatcher. | ||
| */ | ||
| public static CelMatcher compile(CelAbstractSyntaxTree ast) | ||
| throws CelValidationException, CelEvaluationException { | ||
| if (ast.getResultType() != SimpleType.BOOL) { | ||
| throw new IllegalArgumentException( | ||
| "CEL expression must evaluate to boolean, got: " + ast.getResultType()); | ||
| } | ||
| checkAllowedVariables(ast); | ||
| CelRuntime.Program program = RUNTIME.createProgram(ast); | ||
| return new CelMatcher(program); | ||
| } | ||
|
|
||
| /** | ||
| * Compiles the CEL expression string into a CelMatcher. | ||
| */ | ||
| @VisibleForTesting | ||
| public static CelMatcher compile(String expression) | ||
| throws CelValidationException, CelEvaluationException { | ||
| CelAbstractSyntaxTree ast = COMPILER.compile(expression).getAst(); | ||
| return compile(ast); | ||
| } | ||
|
|
||
| /** | ||
| * Evaluates the CEL expression against the input activation. | ||
| */ | ||
| public boolean match(Object input) throws CelEvaluationException { | ||
| Object result; | ||
| if (input instanceof dev.cel.runtime.CelVariableResolver) { | ||
| result = program.eval((dev.cel.runtime.CelVariableResolver) input); | ||
| } else if (input instanceof java.util.Map) { | ||
| @SuppressWarnings("unchecked") | ||
| java.util.Map<String, ?> mapInput = (java.util.Map<String, ?>) input; | ||
| result = program.eval(mapInput); | ||
| } else { | ||
| throw new CelEvaluationException( | ||
| "Unsupported input type for CEL evaluation: " + input.getClass().getName()); | ||
| } | ||
| // Validated to be boolean during compile check ideally, or we cast safely | ||
| if (result instanceof Boolean) { | ||
| return (Boolean) result; | ||
| } | ||
| throw new CelEvaluationException( | ||
| "CEL expression must evaluate to boolean, got: " + result.getClass().getName()); | ||
| } | ||
|
|
||
| private static void checkAllowedVariables(CelAbstractSyntaxTree ast) { | ||
| // Basic validation to ensure only supported variables (request) are used. | ||
| // This iterates over the reference map generated by the type checker. | ||
| for (java.util.Map.Entry<Long, dev.cel.common.ast.CelReference> entry : | ||
| ast.getReferenceMap().entrySet()) { | ||
| dev.cel.common.ast.CelReference ref = entry.getValue(); | ||
| // If overload_id is empty, it's a variable reference or type name. | ||
| // We only support "request". | ||
| if (ref.value() == null && ref.overloadIds().isEmpty()) { | ||
| if (!"request".equals(ref.name())) { | ||
| throw new IllegalArgumentException( | ||
| "CEL expression references unknown variable: " + ref.name()); | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
There is significant code duplication between CelMatcher and CelStringExtractor. Both classes define identical CEL_OPTIONS, COMPILER, and RUNTIME static fields, and have an identical checkAllowedVariables method. The overall structure and logic for compilation and evaluation are also very similar.
To improve maintainability and reduce redundancy, consider refactoring the common code into a shared helper class, for example CelHelper. This helper could contain the static CEL components and the checkAllowedVariables method. CelMatcher and CelStringExtractor would then use this helper, keeping only their specific logic.
| final class OnMatch { | ||
| @Nullable private final UnifiedMatcher nestedMatcher; | ||
| @Nullable private final TypedExtensionConfig action; | ||
| private final boolean isSpecifed; |
There was a problem hiding this comment.
90c750a to
4f0d41a
Compare
Implements gRFC 106: xDS Unified Matcher and CEL Integration
https://github.com/sergiitk/grfc-proposal/blob/a106-xds-unified-matcher-and-cel/A106-xds-unified-matcher-and-cel.md