Skip to content

Fix InternalCategorizationAggregationTests.testReduceRandom #135533

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Sep 29, 2025
Merged

Fix InternalCategorizationAggregationTests.testReduceRandom #135533

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 1 addition & 7 deletions ...rg/elasticsearch/xpack/ml/aggs/categorization/InternalCategorizationAggregationTests.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,12 +46,6 @@ protected SearchPlugin registerPlugin() {
return MachineLearningTests.createTrialLicensedMachineLearning(Settings.EMPTY);
}

@AwaitsFix(bugUrl = "https://github.com/elastic/elasticsearch/issues/87240")
public void testReduceRandom() {
// The bug is in the assertReduced() method immediately below that the base class testReduceRandom() calls.
// To unmute after the bug is fixed, simply delete this entire method so that the base class method is used again.
}

@Override
protected void assertReduced(InternalCategorizationAggregation reduced, List<InternalCategorizationAggregation> inputs) {
Map<Object, Long> reducedCounts = toCounts(reduced.getBuckets().stream());
Expand Down Expand Up @@ -80,7 +74,7 @@ protected InternalCategorizationAggregation createTestInstance(
name,
randomIntBetween(10, 100),
randomLongBetween(1, 10),
randomIntBetween(1, 100),
randomIntBetween(50, 100),
Copy link
Contributor Author

@jan-elastic jan-elastic Sep 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

The failing test had a low similarity threshold and two categories that had a matching 3-letter word. This caused these categories to be merged, leading to unexpected results.

With a higher threshold (which is more realistic anyway), this should not happen anymore.

Copy link
Contributor

Choose a reason for hiding this comment

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

Does this mean that the test expects that no categories should ever be merged? If so, this assumption makes the test a little weak, since if none of the aggregations that are being reduced actually do anything, we can't really tell if they're being reduced correctly. For example, I could imagine a bug where instead of correctly combining the aggregators, each just overwrites the previous one, and this test would not be able to detect that, because all of the aggregators have the same behaviour of doing nothing.

It might be difficult to produce a deterministic test case where some of the aggregations actually do combine categories without needing to effectively reimplement the aggregation logic in the test, but as it stands, I'm not sure if this test is actually providing much meaningful coverage.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All of that is tested in the different other tests in this package.

This test doesn't provide much coverage for categorize text anyway, because random strings generally lead to categories with one string each.

The problem is that the categorize text agg is special, in the sense that it merges / changes keys in the reduce step. No other agg does that (afaik), and the framework isn't compatible with it. In this way, at least some basic properties are verified.

metadata,
buckets
);
Expand Down