[Calcite] Make containsNestedAggregator tolerate flat-leaf schemas

[mch2]

Description

The check splits each aggregator argument on '.' and looks up the
leading token as a top-level ARRAY column (the OpenSearch nested
marker). It used relBuilder.field(root), which throws when the column
doesn't exist.

That works for the classic path, which always exposes a top-level
column for object/nested parents. It breaks the analytics-engine
path, which emits only flat leaves ("city.name", "city.location.latitude")
— parent placeholders can't round-trip through Substrait. Any
aggregation against an object-field leaf (e.g. stats max(city.location.latitude))
crashed with "Field [city] not found".

Use RelDataType.getField, which returns null on miss. A null lookup
is the correct "not nested" answer. Behavior unchanged for relations
that do have a top-level ARRAY column.

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit ba80518)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to ba80518
Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Add index bounds validation Add bounds checking before accessing the field name by index. If r.getIndex() exceeds the size of getFieldNames(), this will throw an IndexOutOfBoundsException. Validate the index is within bounds before accessing. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [1551-1559] return aggCallRefs.stream() + .filter(r -> r.getIndex() < rowType.getFieldNames().size()) .map(r -> rowType.getFieldNames().get(r.getIndex())) .map(name -> org.apache.commons.lang3.StringUtils.substringBefore(name, ".")) .anyMatch( root -> { RelDataTypeField field = rowType.getField(root, /* caseSensitive= */ true, /* elideRecord= */ false); return field != null && field.getType().getSqlTypeName() == SqlTypeName.ARRAY; }); Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential IndexOutOfBoundsException risk when accessing rowType.getFieldNames().get(r.getIndex()). Adding bounds checking is a valid defensive programming practice, though the likelihood of this occurring depends on the upstream data integrity guarantees.	Medium

---

Previous suggestions

Suggestions up to commit 772be11

Category	Suggestion	Impact
Possible issue	Add index bounds validation Add bounds checking before accessing the field name by index. If r.getIndex() exceeds the size of getFieldNames(), this will throw an IndexOutOfBoundsException. Consider validating the index or using a safer access pattern. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [1551-1557] return aggCallRefs.stream() + .filter(r -> r.getIndex() < rowType.getFieldCount()) .map(r -> rowType.getFieldNames().get(r.getIndex())) .map(name -> org.apache.commons.lang3.StringUtils.substringBefore(name, ".")) .anyMatch(root -> { RelDataTypeField field = rowType.getField(root, /*caseSensitive=*/ true, /*elideRecord=*/ false); return field != null && field.getType().getSqlTypeName() == SqlTypeName.ARRAY; }); Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential IndexOutOfBoundsException risk when accessing rowType.getFieldNames().get(r.getIndex()). Adding bounds checking with filter(r -> r.getIndex() < rowType.getFieldCount()) is a valid defensive programming practice that improves robustness, though the likelihood of this occurring in practice depends on the upstream data integrity.	Medium

[github-actions]

Persistent review updated to latest commit ba80518