BoolQuery Must, Must-Not and Should type is not consistent

[deMD]

Elastic.Clients.Elasticsearch version: 8.11.0

Elasticsearch version: v 8.4.1

.NET runtime version: 6

Operating system version: Windows 11 Pro 10.0.22631 Build 22631

Description of the problem including expected versus actual behavior:
When building queries using Elastic.Clients.Elasticsearch against an in memory client the type of the Query collection for the BoolQuery is not consistent. If the ICollection only contains a single item the json generated an object, whereas when the collection contain 1+n items it returns an json array of objects.

Steps to reproduce:

1. Using the .Net client to create a SearchRequest containing a BoolQuery with one item in the Must query collection and one with multiple items in the Must query collection.
2. Evaluate the SearchResponse.ApiCallDetails.RequestBodyInBytes in debug mode
3. The first Must items will be an object whereas the second one will be an object array

Expected behavior
What I expect is to always get an array, even if there is only one item in the query. This is not a problem for Elastic itself, but for test driving the creation of the queries based on user input it is extremely annoying to have to do additional checks just to verify the correct query is created.

Below is also an image with on the left a query with multiple simple_query_strings and on the right with only one.

[flobernd]

Hi @deMD,

This behavior is defined in the specification and we refer to it as a "single or many" construct. For example: BoolQuery. While I agree that this is strange API design, there is not much I can do from my side (client). It might be the case, that in this particular place, an array with just a single element is accepted by the server, but that's not always the case.

Just a quick question:

I'm aware that there is no easy way to read the values stored in a descriptor and that even for regular request objects some values are inaccessible. I assume this is the reason you are trying to verify the query based on the JSON output?

[deMD]

Ah too bad then. I'll make sure to have a nice workaround in our test suite for it then.

Yeah that is the reason we check the output. We are currently in the progress of upgrading from NEST to the new client, and want to make sure the requests to the server remain the same. The easiest way to do that is using VerifyTests and then comparing the json output just makes the most sense. A lot less hassle then coming up with a way to use reflection to do it.

[flobernd]

That's an interesting approach! Let me know if you encounter other discrepancies 🙂

[deMD]

Will do! :)