Add variable support to YAML test expression parser #3196
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.
While debugging a YAML test failure in 8.19 I found that our parser does not appear to support variables, as opposite to expressions that are based on the response from the last request. Take the expression
$profile.uidfor example._lookup('$profile.uid')is calledvalueis assigned a dict that was a response in a previous operationstep == '$profile'self._resolve(step)returns the value stored inself._state['profile']and assigns it tostepassert step in valuefailsThe changes to the parser add support for variables such as
$profile. Thevaluevariable is only initialized tolast_responsewhen the expression does not start with a$, which means it is relative to that response. If the expression starts with$we initialize toNone. Then inside the loop we differentiate between a reference to a variable that starts the expression (whenvalueisNone) versus one that is in the middle and should be treated as a key lookup in the current value.The issue that prompted this change is a block of
matchstatements highlighted here: https://github.com/elastic/elasticsearch-clients-tests/blob/8.19/tests/security/50_user_profile.yml#L80-L86, which are currently failing.