I think that the multiline format should be tested in elasticsearch given that the code belongs there? Something along the lines of MultiSearchRequestTests#testMultiLineSerialization?

I think that the multiline format should be tested in elasticsearch given that the code belongs there?

Perhaps not core - MultiSearchTemplateRequest is in a module because of the mustache dependency. Maybe a new class in /:modules:lang-mustache/src/test/java/org.elasticsearch.script.mustache ?

yea I mean where the request sits.

to clarify, I would leave the initial part and test here only the result of RequestConverters#multiSearchTemplate, and would move the multi line serialization roundtrips to another test to be placed where the request lives.

good point, but I don't think that using the default options for search works for all the other API? At least not in theory. maybe we should allow to provide the default ones for each API?

I found this "options" part of the code pretty confusing to be honest. Could do with a quick chat about what's going on here.

IndicesOptions holds some options that can be set at REST (allow_no_indices, Ignore_unavailable, expand_wildcards) and some others that describe the behaviour of an API, which are hardcoded (on purpose). Unfortunately the transport client allows to set also the latter, with catastrophic results though :)

The point is that, for instance, the search API cannot work against closed indices, hence forbid closed indices is set to true in the default search api indices options, which means that closed indices are considered "unavailable". The default indices options matter as they hold default values, but also some values that cannot be overridden (unless you do it from the transport client at your own risk).

This is not a problem in the high-level REST client, as you can potentially set values like forbidClosedIndices etc. but they will be ignored, only the ones supported at REST will be converted to query_string params. That is what we check in these tests. I suspect that this change is needed because of your request comparison which should not be here but rather in the specific test around multiline serialization.

I guess this should have been added as part of #23767 . Can we make this change in a separate PR please? That way it will have a bit more visibility?

OK - that issue/PR will have to be pushed before this one because the fromXContent part of this PR was failing due to the missing tookInMillis property.

would it be possible to extend from AbstractXContentTestCase?

Tried this and not sure it would work - AbstractXContentTestCase tests for equality using toString() on the response object and any exceptions in the server-side instance don't compare exactly with the re-materialized exceptions from Xcontent. Likely this is why the MultiSearchResponseTests (from which I copied this test) does not use this base class.

you can override assertEqualInstances

MultiSearchResponseTests was written before the test base classes were made more flexible, we should probably migrate that too if it works well for your case

curious about this: what problems were there with deprecated values? Given that it's only used in tests, maybe this could be only in the test where it's needed?

The test was randomly picking from enum's values but the "fromString" code in the same enum would barf on one of those values.

Given that it's only used in tests, maybe this could be only in the test where it's needed?

I thought there would be less chance of getting it wrong in future if the enum where the values are decoded also listed the acceptable values it can decode.

ok no biggie

restore the previous indentation? It was the correct one right? ;)

could you add the optional arguments section? I think max_concurrent_searches is the only one of them.

ideally, you would leave this to true and exclude some of the paths where injecting random fields is not supported, I can imagine that the top-level is problematic here and the _source part as well. You can override getRandomFieldsExcludeFilter.

I tried it and the debugger showed me it failing on an unknown random field name (something like "XCZXFDVC"). Is the end goal here to ensure strictness is being enforced (the test correctly rejects and reports any random noise in the xcontent fields) or that tolerance is applied (the rest client will silently tolerate unknown additions)?

that tolerance is applied, it's a way to test forward compatibility of the client.

obviously there are places where we injecting random fields makes no sense, like _source etc

Makes sense. I don't think getRandomFieldsExcludeFilter will be enough and the parsing code in MultiSearchResponse.Item#itemFromXContent will need changing. Currently it has branching logic like this:

 if ("error".equals(fieldName)) {
	item = new Item(null, ElasticsearchException.failureFromXContent(parser));
} else  ...{
	// assume non-error and parse the hits etc
	item = new Item(SearchResponse.innerFromXContent(parser), null);

The getRandomFieldsExcludeFilter only lets me filter on the name but here I would need to filter if the object context being injected into already contains an error field as the code assumes that errors are the only field in an error response.

what made you return false here? checking whether this is expected or not. may have to do with exceptions which are parsed differently compared to their original representation. In that case, we could have an ordinary test without exceptions and a variation of it with exceptions where we disabled this check. We do this already in ListTasksResponseTests

same comments as above, thanks for converting this test though!!!

with the recent changes, I think that you only need the filter above when testing with failures. here and in the other test.