[BUG] TermSet query generates an empty query instead

[DumboJet]

What is the bug?

I cannot build a TermSet query that uses a script.
When I try to do so, an empty query gets sent.

How can one reproduce the bug?

Just use this code that tries to select documents with a field matching any value in a set of values:

var response = openSearchClient.Search<Document>(s => s
            .Index(documentsIndexName)
            .Query(q => q
                .Bool(bq => bq
                    .Must(mq => mq
                         .TermsSet(f => f.Field(d => d.fieldName).Terms(new int[]{3,7,80}).MinimumShouldMatchScript(sr => sr.Source("1"))
                    )
                )
            ));

I have also tried this without success:

return mq.TermsSet(f => f
                .Field(d => d.fieldName)
                .Terms(new int[]{3,7,80})
                .MinimumShouldMatchScript(sr => sr
                                .Source("params.minMatchCount")
                                .Lang(ScriptLang.Expression)
                                .Params(new Dictionary<string, object>{ {"minMatchCount", 1 } })
                )
            );

What is the expected behavior?

A TermSet query gets sent to the OpenSearch node.

What is your host/environment?

Windows 11 Pro

Do you have any screenshots?

Do you have any additional context?

There is this related StackOverflow question: https://stackoverflow.com/q/77143853/2173353
This is what I get in the log file (opensearch_index_search_slowlog.log) :

[documents][0] took[167.3micros], took_millis[0], total_hits[1 hits], stats[], search_type[QUERY_THEN_FETCH], total_shards[1], source[{}], id[], 

I use the latest Nuget package (v.1.5.0).

[DumboJet]

I have now found that using .Terms() probably achieves the same with less pain, but the bug report remains :

var response = openSearchClient.Search<Document>(s => s
            .Index(documentsIndexName)
            .Query(q => q
                .Bool(bq => bq
                    .Must(mq => mq
                         .Terms(f => f.Field(d => d.fieldName).Terms(new int[]{3,7,80})
                    )
                )
            ));

[Xtansia]

Using the following code:

var response = client.Search<Doc>(s => s
            .Index("my-index")
            .Query(q => q
                .Bool(bq => bq
                    .Must(mq => mq
                        .TermsSet(f =>
                            f.Field(d => d.Foo).Terms(new int[] { 3, 7, 80 })
                                .MinimumShouldMatchScript(sr => sr.Source("1"))
                        )
                    )
                )));
        Console.WriteLine(Encoding.UTF8.GetString(response.ApiCall.RequestBodyInBytes));

I'm able to confirm it's generating the expected search query:

{"query":{"bool":{"must":[{"terms_set":{"foo":{"minimum_should_match_script":{"source":"1"},"terms":[3,7,80]}}}]}}}

I can confirm though that if you had initially excluded MinimumShouldMatchScript that the query is treated as conditionless and wouldn't be serialized.

[DumboJet]

Hm...
This looks identical to what I was trying, and which gave me an empty query.
But I have tried again now, and I got a query.

Weird.
Is there any way to make the library throw exceptions when something vital is missing in a query?
I see that there is a .Strict(bool) method, but I am not sure how well it works, and you have to apply it on each sub-query, from what I have seen.

You can close this issue if you like.

[Xtansia]

Weird. Is there any way to make the library throw exceptions when something vital is missing in a query? I see that there is a .Strict(bool) method, but I am not sure how well it works, and you have to apply it on each sub-query, from what I have seen.

You're correct regarding .Strict()/.IsStrict in that there's currently no mechanism to automatically propagate it's behaviour to every branch of a query. If you have suggestions on a good way to provide this behaviour or even a willingness to have a go at implementing it, that'd be fantastic and I'd love to hear your thoughts. Maybe you'd like to file that as a feature request issue? Otherwise we can try re-working this issue to represent the feature request?

[DumboJet]

@Xtansia
Yes, I could create a new feature request issue, and close this issue.
I have not looked deep into the code yet, but if/when I do, I might get more suggestions on how this could be done.

Here is the feature request issue: #375