Skip to content
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.

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

[SPARK-42746][SQL][FOLLOWUP] Fixing potential flakiness in ListAgg golden files #50357

Closed
wants to merge 2 commits into from

Conversation

mihailom-db
Copy link
Contributor

@mihailom-db mihailom-db commented Mar 23, 2025

What changes were proposed in this pull request?

Original PR (#50338) fixed some of the flakiness, but there were more tests that could potentially be flaky. This PR is fixing these issues.

Why are the changes needed?

We should not rely in golden files tests on buffer ordering. This could lead to flakiness in tests and we need to fix it, so that we do not waste resources.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Test only change.

Was this patch authored or co-authored using generative AI tooling?

No.

@github-actions github-actions bot added the SQL label Mar 23, 2025
@mihailom-db mihailom-db changed the title [SPARK-42746][SQL] Fixing potential flakiness in ListAgg golden files [FOLLOW-UP][SPARK-42746][SQL] Fixing potential flakiness in ListAgg golden files Mar 23, 2025
@beliefer beliefer changed the title [FOLLOW-UP][SPARK-42746][SQL] Fixing potential flakiness in ListAgg golden files [SPARK-42746][SQL][FOLLOWUP] Fixing potential flakiness in ListAgg golden files Mar 24, 2025
@@ -1,13 +1,13 @@
-- Test cases with utf8_binary
SELECT listagg(c1) WITHIN GROUP (ORDER BY c1 COLLATE utf8_binary) FROM (VALUES ('a'), ('A'), ('b'), ('B')) AS t(c1);
SELECT listagg(DISTINCT c1 COLLATE utf8_binary) FROM (VALUES ('a'), ('A'), ('b'), ('B')) AS t(c1);
WITH t(c1) AS (SELECT listagg(DISTINCT col1 COLLATE utf8_binary) FROM (VALUES ('a'), ('A'), ('b'), ('B'))) SELECT len(c1), regexp_count(c1, 'a'), regexp_count(c1, 'b'), regexp_count(c1, 'A'), regexp_count(c1, 'B') FROM t;
Copy link
Contributor

@beliefer beliefer Mar 24, 2025

Choose a reason for hiding this comment

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

Could you explain why you introduce this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In tests in general, there is no guarantee that ordering of the column will be the same as the query insertion time, unless we include an order by clause. This is potentially making tests flaky, as golden file tests need to be regenerated, so this PR is only making sure we do not have to rerun CIs for tests potentially flaky tests. Also, it is better to prevent flakiness first, then to leave it for detection later.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we do not need this one if listagg is deterministic.

Copy link
Contributor

Choose a reason for hiding this comment

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

Spark aggregate is not deterministic by nature, as the shuffle reader fetches shuffle blocks in a random order, and they can arrive in a random order.

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it.

@cloud-fan
Copy link
Contributor

thanks, merging to master/4.0!

@cloud-fan cloud-fan closed this in e4b6e9a Mar 24, 2025
cloud-fan pushed a commit that referenced this pull request Mar 24, 2025
…lden files

### What changes were proposed in this pull request?
Original PR (#50338) fixed some of the flakiness, but there were more tests that could potentially be flaky. This PR is fixing these issues.

### Why are the changes needed?
We should not rely in golden files tests on buffer ordering. This could lead to flakiness in tests and we need to fix it, so that we do not waste resources.

### Does this PR introduce _any_ user-facing change?
No.

### How was this patch tested?
Test only change.

### Was this patch authored or co-authored using generative AI tooling?
No.

Closes #50357 from mihailom-db/listaggfollowup2.

Authored-by: Mihailo Milosevic <[email protected]>
Signed-off-by: Wenchen Fan <[email protected]>
(cherry picked from commit e4b6e9a)
Signed-off-by: Wenchen Fan <[email protected]>
SauronShepherd pushed a commit to SauronShepherd/spark that referenced this pull request Mar 25, 2025
…lden files

### What changes were proposed in this pull request?
Original PR (apache#50338) fixed some of the flakiness, but there were more tests that could potentially be flaky. This PR is fixing these issues.

### Why are the changes needed?
We should not rely in golden files tests on buffer ordering. This could lead to flakiness in tests and we need to fix it, so that we do not waste resources.

### Does this PR introduce _any_ user-facing change?
No.

### How was this patch tested?
Test only change.

### Was this patch authored or co-authored using generative AI tooling?
No.

Closes apache#50357 from mihailom-db/listaggfollowup2.

Authored-by: Mihailo Milosevic <[email protected]>
Signed-off-by: Wenchen Fan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants