[Bug](Executor) ARRAY_UNION with empty left array and nested-array right input reaches BE and fails with Unexpected columns

[HappenLee]

Description

ARRAY_UNION fails on the backend when the left argument is an empty array and the right argument contains nested arrays. The expression reaches the BE and then reports an error like Unexpected columns.

Discussion Summary

• The issue occurs when ARRAY_UNION is used with an empty left array and a nested-array right input.
• Related functions already support nested arrays; for example, array_distinct(array_concat([[[1], [2]]], ...)) returns nested arrays.
• Extending the BE implementation of ARRAY_UNION to properly handle nested-array inputs is preferable to adding FE-side restrictions.

Expected Behavior

ARRAY_UNION should either return a clean result for nested-array inputs or be rejected cleanly at the FE/BE boundary if unsupported. The current failure happens inside the BE, which is not user-friendly.

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_006b7425fa13
This content is generated by AI for reference only.

Initial triage for #65356:

I reread the live issue. It is open, currently has no labels, no comments, and no affected version field, so I inspected current upstream/master read-only.

Preliminary judgment: this looks like a real analyzer/executor mismatch around ARRAY_UNION, not just an unhelpful message. Current public regression coverage already expects ARRAY_UNION(array_array, array_array) to be rejected with array_union does not support types: ARRAY<ARRAY<INT>>, so nested array elements are not consistently supported by ARRAY_UNION today. The empty-left-array shape can bypass that clean rejection because ArrayUnion.checkLegalityBeforeTypeCoercion() only checks argument 0 before type coercion. If argument 0 is an empty array literal, it may not expose the final nested-array item type until coercion with the right argument.

Relevant current code path:

• FE: fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/scalar/ArrayUnion.java checks only getArgument(0) for complex/variant/json array item types.
• BE: be/src/exprs/function/array/function_array_union.cpp registers FunctionArrayNary<ArrayMapImpl<MapOperation::UNION>, NameArrayUnion>.
• BE dispatch: be/src/exprs/function/array/function_array_map.h executes only _execute_internal<ALL_COLUMNS_SIMPLE>. ALL_COLUMNS_SIMPLE is numeric/time/string/IP columns, not ColumnArray. When the item type is itself an array, the nested column is ColumnArray, so the dispatch cannot match and falls back to Unexpected columns.

Recommended next step:

1. Decide the intended contract for ARRAY_UNION on nested arrays. If nested arrays should be supported, the fix should be in the BE set/map implementation, with real hash/equality/copy handling for ColumnArray elements, including nested offsets and nested null maps.
2. If nested arrays should remain unsupported for ARRAY_UNION, the minimum fix is to make the analyzer reject all argument positions cleanly, not only argument 0. ArrayIntersect.checkLegalityBeforeTypeCoercion() is a closer existing pattern because it iterates over all arguments and handles null/empty-array typing more deliberately.
3. In either direction, the BE should not expose raw Unexpected columns for a user-level type/capability miss.

Suggested regression coverage:

• array_union([], [[[1], [2]]])
• a non-empty nested-array left input with nested-array right input
• varargs with one empty array and one nested-array argument
• nullable nested elements, if nested support is chosen
• ordering-insensitive verification, since the current union path materializes results from a hash map

Missing information to fully close the issue:

• Exact failing SQL and the full returned error text.
• Affected Doris version or commit.
• Whether the failure is Nereids-only.
• Expected duplicate-comparison semantics for nested arrays if support is added.