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
Improve rest-api-spec test runner to disallow malformatted request definitions #34651
Labels
Comments
Pinging @elastic/es-core-infra |
cc @elastic/es-clients |
javanna
added a commit
to javanna/elasticsearch
that referenced
this issue
Oct 23, 2018
We throw parsing exception when an unknown array is found, but we don't when an unknown top-level field is found. This commit makes sure that unsupported top-level fields are not ignored in a do section. Closes elastic#34651
I opened #34734 to address the described problem in a do section. If you find similar issues elsewhere, please open an issue and I'll address ;) |
javanna
added a commit
that referenced
this issue
Oct 24, 2018
We throw parsing exception when an unknown array is found, but we don't when an unknown top-level field is found. This commit makes sure that unsupported top-level fields are not ignored in a do section. Closes #34651
kcm
pushed a commit
that referenced
this issue
Oct 30, 2018
We throw parsing exception when an unknown array is found, but we don't when an unknown top-level field is found. This commit makes sure that unsupported top-level fields are not ignored in a do section. Closes #34651
javanna
added a commit
that referenced
this issue
Nov 1, 2018
We throw parsing exception when an unknown array is found, but we don't when an unknown top-level field is found. This commit makes sure that unsupported top-level fields are not ignored in a do section. Closes #34651
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
The Elasticsearch rest-api-spec test runner should be made stricter to disallow malformatted requests.
For example, as you can see in this pull request, the parameters defined for the
msearch
request were not properly placed under the request name key (msearch
). They were instead sister keys to the request name.I opened the pull request because the Ruby client was throwing an error when parsing this spec.
Perhaps the parameters defined in this test do not have an effect on the response and the test runner just looks for a key that maps to an api endpoint, skipping other keys that are at the same level as the request name.
The text was updated successfully, but these errors were encountered: