Fix ClassCastException for value-storing aggregates on nested PPL fields

[ahkcs]

Summary

Value-storing aggregate functions (first, last, min, max) failed with a ClassCastException when targeting deeply nested field paths such as resource.attributes.telemetry.sdk.language.
This PR fixes nested-field value extraction in OpenSearch SQL by handling Map/HashMap objects that represent nested structures, eliminating the unsafe cast and restoring expected behavior for value-storing aggregates.

---

Problem

These queries previously failed with ClassCastException for value-storing aggregates:

source=logs-otel-v1* | stats first(`resource.attributes.telemetry.sdk.language`) by severityNumber
source=logs-otel-v1* | stats last(`resource.attributes.telemetry.sdk.language`) by severityNumber
source=logs-otel-v1* | stats min(`resource.attributes.telemetry.sdk.name`) by severityNumber
source=logs-otel-v1* | stats max(`resource.attributes.telemetry.sdk.name`) by severityNumber

While simple fields worked:

source=logs-otel-v1* | stats first(severityNumber)

Note: Calculation-only aggregates like count() and dc() were unaffected because they don’t store field values.

Observed error:

{
  "error": {
    "reason": "There was internal problem at backend",
    "details": "class java.util.HashMap cannot be cast to class java.lang.String",
    "type": "ClassCastException"
  }
}

---

Root Cause

Execution-path analysis showed the failure at the final type-conversion layer in value-storing aggregates:

1. Field resolution returned partial Map structures (e.g., {attributes={telemetry={sdk={language=java}}}}) instead of the terminal primitive ("java").
2. Aggregates (first, last, min, max) stored these Map objects in their accumulators.
3. Type conversion later attempted (String) value in ObjectContent.stringValue() where value was a Map.

Why calculation-only aggregates work: functions like count() and dc() perform calculations without storing the actual field values, so they never hit this conversion path.

---

Solution

Implement nested-map handling in ObjectContent.stringValue() so value-storing aggregate outputs can be safely converted to strings.

Key changes

• Detect Map values and recursively extract the terminal primitive via extractFinalPrimitiveValue(...).
• Preserve existing behavior for non-Map values (backward compatible).

Before

return (String) value;  // throws ClassCastException if value is a Map

After

if (value instanceof Map) {
  Map<String, Object> map = (Map<String, Object>) value;
  Object finalValue = extractFinalPrimitiveValue(map); // drills down single-value maps
  if (finalValue != null && !(finalValue instanceof Map)) {
    return finalValue.toString();
  }
  return map.toString();
}
return (String) value;

Example extraction
Input: {attributes={telemetry={sdk={language=java}}}}
→ {telemetry={sdk={language=java}}}
→ {sdk={language=java}}
→ {language=java}
→ "java"

---

Verification (now succeeds)

source=logs-otel-v1* | stats first(`resource.attributes.telemetry.sdk.language`) by severityNumber
source=logs-otel-v1* | stats last(`resource.attributes.telemetry.sdk.language`) by severityNumber
source=logs-otel-v1* | stats min(`resource.attributes.telemetry.sdk.language`) by severityNumber
source=logs-otel-v1* | stats max(`resource.attributes.telemetry.sdk.language`) by severityNumber

Resolves

• Resolves [BUG] ClassCastException for value-storing aggregates on nested PPL fields #4359

[LantaoJin]

What if the type of nested language is an integer, can the ppl work?

[ahkcs]

Yes, in ObjectContent.java, first the extractFinalPrimitiveValue method will extract the value as Object and then we'll add toString() to it.

[LantaoJin]

No I mean what if the mapping contains

                    "properties": {
                      "version": {
                        "type": "integer"
                      }

and query with | stats min(`resource.attributes.telemetry.sdk.version`).
Can you update the mapping and data, and test above query?

[ahkcs]

Changed the approach - moved the fix from ObjectContent.java to OpenSearchExprValueFactory.construct() for better universal handling. Updated the telemetry mapping to test for types like integer and boolean

[Swiddis]

Is there risk of a RecursionError here?

If this is only loaded from an index, it's maybe fine (I think you can't index massively nested structures, not sure). But if there's a path where this is executed on user input, it'd be very easy to cause a crash with this.

[LantaoJin]

LGTM if the CI rerun passed.

[opensearch-trigger-bot]

The backport to 2.19-dev failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/sql/backport-2.19-dev 2.19-dev
# Navigate to the new working tree
pushd ../.worktrees/sql/backport-2.19-dev
# Create a new branch
git switch --create backport/backport-4360-to-2.19-dev
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e92bf68f67577ba42112e47232ffe86f6c32c909
# Push it to GitHub
git push --set-upstream origin backport/backport-4360-to-2.19-dev
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/sql/backport-2.19-dev

Then, create a pull request where the base branch is 2.19-dev and the compare/head branch is backport/backport-4360-to-2.19-dev.

[LantaoJin]

@ahkcs please manually backport it, thanks