Skip to content
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

Ignore warnings related to types deprecation in REST tests. #35395

Merged
merged 3 commits into from
Nov 13, 2018
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -301,10 +301,14 @@ void checkWarningHeaders(final List<String> warningHeaders, final Version master
* This warning header will come back in the vast majority of our tests that create an index when running against an
* older master. Rather than rewrite our tests to assert this warning header, we assume that it is expected.
*/
} else {
if (expected.remove(message) == false) {
unexpected.add(header);
}
} else // noinspection StatementWithEmptyBody
if (message.startsWith("[types removal]")) {
/*
* We skip warnings related to types deprecation so that we can continue to run the many
* mixed-version tests that used typed APIs.
*/
} else if (expected.remove(message) == false) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be indented a level so the close bracket lines up with the if it relates to?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think so, think of it as a multi-line if:

 if (a
     || b
     || c) {
   // do something
 }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignore me. We don't indent chains of else ifs and this just threw me because the else is separated from the if by a comment.

unexpected.add(header);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this change requires some adapting on language clients test runners. I think that some clients don't support headers, hence they can't support the warning feature, so this does not affect them (they already skip all the tests around warnings and don't fail if warnings are returned). Not sure what other clients that support headers do though. If they do fail when a warning is returned, which they should, their runner should be adapted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @javanna for the note, I'll make sure to tag the clients team on these PRs.

}
} else {
unmatched.add(header);
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -128,6 +128,16 @@ public void testWarningHeaders() {
}
}

public void testIgnoreTypesWarnings() {
String legitimateWarning = DeprecationLogger.formatWarning("warning");
String typesWarning = DeprecationLogger.formatWarning("[types removal] " +
"The endpoint /{index}/{type}/_count is deprecated, use /{index}/_count instead.");

DoSection section = new DoSection(new XContentLocation(1, 1));
section.setExpectedWarningHeaders(singletonList("warning"));
section.checkWarningHeaders(Arrays.asList(legitimateWarning, typesWarning), Version.CURRENT);
}

public void testParseDoSectionNoBody() throws Exception {
parser = createParser(YamlXContent.yamlXContent,
"get:\n" +
Expand Down