Skip to content

Conversation

@ahkcs
Copy link
Contributor

@ahkcs ahkcs commented Aug 24, 2025

Description

Support distinct_count/dc in eventstats #4084

ahkcs and others added 3 commits August 24, 2025 16:37
Signed-off-by: Kai Huang <ahkcs@amazon.com>
Signed-off-by: Kai Huang <105710027+ahkcs@users.noreply.github.com>
(cherry picked from commit b220be4)
Signed-off-by: Kai Huang <ahkcs@amazon.com>
Signed-off-by: Kai Huang <ahkcs@amazon.com>
executeQuery(
String.format(
"source=%s | eventstats dc(state) as dc_state", TEST_INDEX_STATE_COUNTRY));
"source=%s | eventstats dc(state) as dc_state | fields name, country, state, month, year, age, dc_state", TEST_INDEX_STATE_COUNTRY));
Copy link
Member

Choose a reason for hiding this comment

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

why fields required in these ITs.

Copy link
Contributor Author

@ahkcs ahkcs Aug 25, 2025

Choose a reason for hiding this comment

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

It will cause the CI to fail, local testing was successful without fields

Copy link
Member

Choose a reason for hiding this comment

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

It will cause the CI to fail, local testing was successful without fields

If the original tests were successful without this PR, sounds a potential bug is introducing in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The CI failure is this PR was caused by the order of the schema, and this failure also is not able to be reproduced locally. I suspect that it's triggered by different testing environment in CI and local. Do you think we should also add this fields to main for consistency in this case?

Copy link
Member

Choose a reason for hiding this comment

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

and this failure also is not able to be reproduced locally. I suspect that it's triggered by different testing environment in CI and local.

The question is how the PR introduced a reproduced CI failure. we need to figure out the reason.

Copy link
Member

@LantaoJin LantaoJin left a comment

Choose a reason for hiding this comment

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

In addition to Java-version-specific fixes in backporting, do not simply modify original tests during backporting. At minimum, provide an explanation for why you're bypassing the issue rather than resolving it fundamentally.

ahkcs and others added 2 commits August 24, 2025 22:43
Signed-off-by: Kai Huang <105710027+ahkcs@users.noreply.github.com>
Signed-off-by: Kai Huang <ahkcs@amazon.com>
@ahkcs
Copy link
Contributor Author

ahkcs commented Aug 25, 2025

In addition to Java-version-specific fixes in backporting, do not simply modify original tests during backporting. At minimum, provide an explanation for why you're bypassing the issue rather than resolving it fundamentally.

The CI failure was reproduced locally by switching to Java 11. Since different Java version will cause the order of the schema to be different, should we add the fields on both main and 2.19-dev backport to ensure output consistency for different Java versions?

@ahkcs ahkcs requested a review from LantaoJin August 25, 2025 22:22
@LantaoJin
Copy link
Member

In addition to Java-version-specific fixes in backporting, do not simply modify original tests during backporting. At minimum, provide an explanation for why you're bypassing the issue rather than resolving it fundamentally.

The CI failure was reproduced locally by switching to Java 11. Since different Java version will cause the order of the schema to be different, should we add the fields on both main and 2.19-dev backport to ensure output consistency for different Java versions?

Do you mean when move to Java 11, even without your PR, the CI will fail either. If yes, we can add fields. But if this failures only happened with your PR, we still need to investigate why the PR changed something.

@ahkcs
Copy link
Contributor Author

ahkcs commented Aug 26, 2025

Do you mean when move to Java 11, even without your PR, the CI will fail either. If yes, we can add fields. But if this failures only happened with your PR, we still need to investigate why the PR changed something.

The CI failure is specifically for my distinct_count test cases, no other tests failed

For testing in main, the project requires Java 21 minimum. In 2.19-dev branch, I have confirmed that CI failure can be reproduced locally with Java 11. When using Java 21, the integration test will pass locally.

By local testing I mean the local branch for this PR

@ykmr1224
Copy link
Collaborator

ykmr1224 commented Sep 3, 2025

@ahkcs @LantaoJin
I think we can put @Ignore to the failing test cases for this specific PR, but we should fix it to return result with consistent order regardless of the environment.

ahkcs and others added 2 commits September 3, 2025 09:01
Signed-off-by: Kai Huang <105710027+ahkcs@users.noreply.github.com>
Signed-off-by: Kai Huang <ahkcs@amazon.com>
@ykmr1224 ykmr1224 merged commit 9de8593 into opensearch-project:2.19-dev Sep 3, 2025
24 checks passed
@LantaoJin
Copy link
Member

FYI. This PR is intended to resolve the issue of result ordering inconsistencies across different Java versions. #3740

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants