fix: handle nested arrays in UNNEST by checking for grouping in left query (#17949)

[zhang-arvin]

Description

Fixes #17949: UNNEST with nested arrays fails when the left side of the correlate contains GROUP BY aggregation.

Root Cause

DruidCorrelateUnnestRel.toDruidQuery() uses computeLeftRequiresSubquery() to determine whether to wrap the left query in a QueryDataSource. However, computeLeftRequiresSubquery() only checks the PartialDruidQuery stage (SCAN), but when UNNEST is pulled up above a GROUP BY, the left side may contain grouping/aggregation pushed into the DruidQuery itself. In this case, getDataSource() returns the raw table scan instead of a subquery that wraps the aggregation.

Fix

Added an additional check in toDruidQuery(): when the computed updatedLeftQuery is a GroupByQuery (i.e., contains grouping), wrap it in a QueryDataSource even if computeLeftRequiresSubquery() returns false. This ensures the grouping/aggregation logic is preserved in the UNNEST data source.

Changes

• sql/src/main/java/org/apache/druid/sql/calcite/rel/DruidCorrelateUnnestRel.java: Added instanceof GroupByQuery check in the toDruidQuery() method to detect when the left query contains grouping, and use QueryDataSource accordingly.

[FrankChen021]

Severity	Findings
P0	0
P1	1
P2	0
P3	0
Total	1

Reviewed 1 of 1 changed files.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

[P1] GroupBy detection is unreachable

This check runs only when the partial-query stage is SCAN, WHERE_FILTER, or SELECT_PROJECT. DruidQuery emits GroupByQuery only when an aggregate exists, which places the stage at AGGREGATE or later. Therefore the new condition cannot change the data-source choice for the reported grouped-left-side case, leaving the fix ineffective.

[FrankChen021]

Severity	Findings
P0	0
P1	1
P2	0
P3	0
Total	1

Reviewed 1 of 1 changed files.

The review found one high-confidence P1 correctness issue in the grouped-left UNNEST rewrite.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

[P1] GroupByQuery check is too late to preserve grouped rows

The rewrite above can rebuild a grouped left relation from only its scan/project before this check, making updatedLeftQuery a ScanQuery rather than a GroupByQuery. A query that groups an array column and then UNNESTs it can therefore still read raw pre-group rows and return duplicates or incorrect results. Detect and preserve grouping before rebuilding the left query, with a regression test.

[zhang-arvin]

@FrankChen021 Thanks for the review! I have fixed the GroupByQuery check:

P1 fix: Moved the GroupByQuery check out of the stage <= SELECT_PROJECT block to be an independent condition. Previously, the GroupByQuery check was unreachable because it was nested inside the whereFilter == null branch which only executes before the AGGREGATE stage — but GroupByQuery only appears at or after AGGREGATE.

The fix ensures that when the left side query is a GroupByQuery, it is always used as a subquery datasource regardless of the current stage, preventing the UNNEST from reading pre-grouping rows and producing duplicates.

Note: The CI failures (17/21) are caused by master branch drift — DataSourceCompactibleSegmentIteratorTest was migrated from JUnit 4 to JUnit 5 on master. This is unrelated to the PR changes. I will rebase onto master in a follow-up push.

[FrankChen021]

I have reviewed the code for correctness, edge cases, concurrency, and integration risks; no issues found.

Reviewed 1 of 1 changed files. The prior grouping concern appears resolved in the current head.

Validation: focused git diff --check passed. Builds and tests were not run.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

can you add a test case for this change ?