Change:
attributes:           endpointCreateAttributes(), expression:           "variables.name == 'endpoints1'", expectErr:            true, <del> expectedErrorMessage: `composited variable "name" fails to compile:`, </del> <ins> expectedErrorMessage: `found no matching overload for '_==_' applied to '(int, string)'`, </ins> }, { name: "delayed eval error", variables: []NamedExpressionAccessor{ &testVariable{ <del> name:       "name", expression: "object.spec.subsets[114514].addresses.size()", // array index out of bound </del> <ins> name:       "count", expression: "object.subsets[114514].addresses.size()", // array index out of bound </ins> }, }, attributes:           endpointCreateAttributes(), <del> expression:           "variables.name == 'endpoints1'", </del> <ins> expression:           "variables.count == 810", </ins> expectErr:            true, <del> expectedErrorMessage: `composited variable "name" fails to evaluate:`, </del> <ins> expectedErrorMessage: `composited variable "count" fails to evaluate: index out of bounds: 114514`, </ins> }, { name: "out of budget during lazy evaluation",

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign