Change:
expectedResult:    true, runtimeCostBudget: 10, // enough for one lazy evaluation but not two, should pass }, <ins> { name: "single boolean variable in expression", variables: []NamedExpressionAccessor{ &testVariable{ name:       "fortuneTelling", expression: "true", }, }, attributes:     endpointCreateAttributes(), expression:     "variables.fortuneTelling", expectedResult: true, }, { name: "variable of a list", variables: []NamedExpressionAccessor{ &testVariable{ name:       "list", expression: "[1, 2, 3, 4]", }, }, attributes:     endpointCreateAttributes(), expression:     "variables.list.sum() == 10", expectedResult: true, }, { name: "variable of a map", variables: []NamedExpressionAccessor{ &testVariable{ name:       "dict", expression: `{"foo": "bar"}`, }, }, attributes:     endpointCreateAttributes(), expression:     "variables.dict['foo'].contains('bar')", expectedResult: true, }, { name: "variable of a list but confused as a map", variables: []NamedExpressionAccessor{ &testVariable{ name:       "list", expression: "[1, 2, 3, 4]", }, }, attributes:           endpointCreateAttributes(), expression:           "variables.list['invalid'] == 'invalid'", expectErr:            true, expectedErrorMessage: "found no matching overload for '_[_]' applied to '(list(int), string)'", }, { name: "list of strings, but element is confused as an integer", variables: []NamedExpressionAccessor{ &testVariable{ name:       "list", expression: "['1', '2', '3', '4']", }, }, attributes:           endpointCreateAttributes(), expression:           "variables.list[0] == 1", expectErr:            true, expectedErrorMessage: "found no matching overload for '_==_' applied to '(string, int)'", }, </ins> } for _, tc := range cases { t.Run(tc.name, func(t *testing.T) {

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