fix(array_agg): reverse ordering_values in state() when accumulator is reversed

[ologlogn]

Which issue does this PR close?

No existing issue. Discovered while investigating incorrect results from ARRAY_AGG(x ORDER BY y DESC) in a multi-partition query.

Rationale for this change

Bug description

When multiple ARRAY_AGG expressions with conflicting ORDER BY directions (ASC and DESC) appear in the same query, results for the DESC variant are silently wrong.

How the optimizer creates the bug path

The bug is triggered deterministically by a well-defined optimizer pipeline. Take this query:

SELECT
  ARRAY_AGG(c1 ORDER BY c1 ASC),
  ARRAY_AGG(c1 ORDER BY c1 DESC)
FROM t

Step 1 — get_finer_aggregate_exprs_requirement (runs at AggregateExec construction)

This function iterates the aggregate expressions to find a single common ordering requirement that the input sort can satisfy:

1. Takes the first aggregate's requirement → common = [c1 ASC]
2. Second aggregate needs [c1 DESC] — conflicts with [c1 ASC]
3. Checks reverse of second: reverse(DESC) = ASC → [c1 ASC] satisfies it
4. Mutates aggr_expr[1] in-place: flips ARRAY_AGG(c1 DESC) → ARRAY_AGG(c1 ASC, is_reversed=true)
5. AggregateExec::required_input_ordering is set to [c1 ASC] (soft requirement)

The DESC aggregate is already reversed to ASC before any other rule runs.

Step 2 — EnsureRequirements optimizer

Sees required_input_ordering = [c1 ASC] → inserts SortExec [c1 ASC] before the partial aggregate.

Step 3 — OptimizeAggregateOrder optimizer

Runs on the partial aggregate (input mode = Raw). Input is now sorted [c1 ASC]. For each aggregate:

• ARRAY_AGG(c1 ASC): direct match → is_input_pre_ordered=true, reverse=false ✓
• ARRAY_AGG(c1 ASC, is_reversed=true) (already mutated): direct match → is_input_pre_ordered=true, reverse=true ← bug path

The DESC accumulator ends up with ordering_req=[c1 ASC], is_input_pre_ordered=true, reverse=true.

Root cause

In OrderSensitiveArrayAggAccumulator::state():

let mut result = vec![self.evaluate()?];   // reverses values list → DESC order ✓
result.push(self.evaluate_orderings()?);    // ordering keys stay in original ASC order ✗

evaluate() reverses self.values (ASC input → DESC output), but evaluate_orderings() always iterated self.ordering_values forward. The partial state emits a mismatched pair: values in DESC order, ordering keys in ASC order.

The final accumulator's merge_batch uses merge_ordered_arrays with the ordering keys to decide k-way merge priority. Because the keys are paired with the wrong values, the merge produces the wrong order — silently, no error or panic.

Note: if DESC is listed first and ASC second, the roles are swapped — the ASC aggregate gets reversed and its result is wrong instead. The bug always hits whichever aggregate get_finer_aggregate_exprs_requirement reverses.

What changes are included in this PR?

Single change in evaluate_orderings() inside OrderSensitiveArrayAggAccumulator:

// Before
let column_values = self.ordering_values.iter().map(|x| x[i].clone());

// After
let column_values: Box<dyn Iterator<Item = ScalarValue>> = if self.reverse {
    Box::new(self.ordering_values.iter().rev().map(|x| x[i].clone()))
} else {
    Box::new(self.ordering_values.iter().map(|x| x[i].clone()))
};

When reverse=true, ordering keys are iterated in reverse to match the reversed values emitted by evaluate(), so merge_batch receives correctly paired (value, ordering_key) entries.

Are these changes tested?

Unit test — desc_order_partial_final_merge_correct in array_agg.rs directly exercises the partial→final merge path with a reversed accumulator (is_input_pre_ordered=true, reverse=true). Before fix: [3, 4, 5, 0, 1, 2]. After fix: [5, 4, 3, 2, 1, 0].

SQL logic test — regression test in aggregate.slt runs the exact bug-triggering query against a real 10-row table:

SELECT array_agg(c1 ORDER BY c1), array_agg(c1 ORDER BY c1 DESC) FROM agg_order;

The EXPLAIN confirms SortExec [c1 ASC] + Partial/Final stages (the optimizer path that triggers the bug). The result assertion catches the wrong output:

-- without fix (wrong):
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]  [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

-- with fix (correct):
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]  [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]

Are there any user-facing changes?

Yes — ARRAY_AGG(x ORDER BY y DESC) now returns correct results when the query uses multi-partition execution and the optimizer reverses the partial accumulator.

[gabotechs]

Looks good, thanks @ologlogn!

[gabotechs]

I'll leave this here for a day in order to give chance to other to chime in, and otherwise will merge on monday.