[AUTOCUT] Gradle Check Flaky Test Report for MinDocCountIT

[opensearch-ci-bot]

Flaky Test Report for MinDocCountIT

Noticed the MinDocCountIT has some flaky, failing tests that failed during post-merge actions.

Details

Git Reference	Merged Pull Request	Build Details	Test Name
42d6af6	14123	40485	org.opensearch.search.aggregations.bucket.MinDocCountIT.testDoubleCountDesc {p0={"search.concurrent_segment_search.enabled":"true"}}
c639e9a	14090	40463	org.opensearch.search.aggregations.bucket.MinDocCountIT.testHistogramKeyDesc {p0={"search.concurrent_segment_search.enabled":"true"}}

The other pull requests, besides those involved in post-merge actions, that contain failing tests with the MinDocCountIT class are:

• 13172
• 13835
• 14115
• 13821
• 13865
• 13924
• 14464
• 13870
• 13997
• 13461
• 14086

For more details on the failed tests refer to OpenSearch Gradle Check Metrics dashboard.

[jed326]

Looks like the MinDocCountIT.testDoubleCountDesc failure above is due to concurrent thread context modification bug for which fix has been merged: #14084

[jed326]

A quick scan through the other not post-merge related failures indicates that most of the other MinDocCountIT are due to the same issue fixed in #14084.

[jed326]

The failure for MinDocCountIT.testHistogramKeyDesc looks like it's finding an incorrect doc count for a given bucket key when minDocCount is used.

It's possible that this is due to concurrent search and minDocCount not being satisfied on one of the shards but it's also possible that it's due to one of the histogram rewrite changes. Unfortunately was not able to reproduce locally with the test seed.

[jed326]

My hunch was that this could be similar to the issue in #9085 for terms aggregations, however based on

OpenSearch/server/src/main/java/org/opensearch/search/aggregations/bucket/histogram/InternalHistogram.java

Lines 335 to 337 in e354201

	if (reduced.getDocCount() >= minDocCount || reduceContext.isFinalReduce() == false) {
	reducedBuckets.add(reduced);
	}

it looks like minDocCount is only applied during the coordinator reduce which makes it unlikely that the this is due to concurrent search as the shard search requests should be identical in both cases.

Will defer to @bowenlan-amzn for any insights related to the recent histogram optimizations.