[FEATURE] Define a schema-conflict and mismatched-data handling policy for multi-index queries

Is your feature request related to a problem?

Querying across multiple indices (e.g. a wildcard index pattern like source=logs-*) has no consistent policy for handling two related but distinct problems:

1. Schema-merge-time conflicts: the same field name has genuinely incompatible mapping types across backing indices (e.g. object in some, scalar text in others). MergeRuleHelper currently resolves conflicts via an ordered rule chain:
   • DeepMergeRule only merges struct-vs-struct sub-properties.
   • TextKeywordConflictRule only resolves scalar-vs-scalar (text/keyword) conflicts.
   • Any other mismatch falls through to LatestRule, which silently picks whichever backing index's mapping was processed last, with no validation, error or coercion.
2. Execution-time mismatched data: even once a unified schema is settled on, an individual document's actual value can still fail to match the declared type for that field — not because the document is malformed, but because it came from a differently-mapped index (e.g. dynamic mapping drift across backing indices, or one index legitimately storing the field as a plain string while another stores it as a nested object). OpenSearchExprValueFactory blindly casts each document's raw value to the declared type with no defensive handling, so a document from a mismatched-mapping shard throws:

java.lang.ClassCastException: class java.lang.String cannot be cast to class java.util.Map
  at org.opensearch.sql.opensearch.data.utils.ObjectContent.map(ObjectContent.java:81)
  at org.opensearch.sql.opensearch.data.value.OpenSearchExprValueFactory.parseStruct(OpenSearchExprValueFactory.java:376)
  at org.opensearch.sql.opensearch.data.value.OpenSearchExprValueFactory.parse(OpenSearchExprValueFactory.java:218)
  at org.opensearch.sql.opensearch.data.value.OpenSearchExprValueFactory.construct(OpenSearchExprValueFactory.java:189)
  at org.opensearch.sql.opensearch.response.OpenSearchResponse.lambda$handleAggregationResponse$2(OpenSearchResponse.java:263)
  at org.opensearch.sql.opensearch.storage.scan.OpenSearchIndexEnumerator.moveNext(OpenSearchIndexEnumerator.java:139)

What solution would you like?

Solutions generally fall into four strategies. Some apply only at execution time (per document, during row deserialization); others apply at both schema-merge time (before query execution, once per index-pattern resolution) and execution time, depending on where they're implemented. Rather than hardcoding a single strategy, these could be exposed as a configurable mode, similar to Spark's CSV/JSON reader mode option (PERMISSIVE, FAILFAST, DROPMALFORMED), letting users choose the behavior that fits their use case:

What alternatives have you considered?

• Schema-on-read with no unified type: the most permissive, but a much larger architectural change inconsistent with OpenSearch SQL/PPL's current Calcite-based single-row-schema design.
• A VARIANT-like semi-structured type for conflicting fields: would require a new core data type and query syntax (field:path::type), a larger change than extending the existing merge/parsing layers.

Do you have any additional context?

Related work

This gap has been patched twice before, each time narrowly for one specific type pairing rather than as a general policy:

Examples

Minimal reproduction (OpenSearch 3.8.0-SNAPSHOT, main HEAD):

PUT /log-repro-object
{
  "mappings": {
    "properties": {
      "log": { "properties": { "ts": { "type": "date" } } }
    }
  }
}

PUT /log-repro-scalar
{
  "mappings": {
    "properties": {
      "log": { "type": "text" }
    }
  }
}

POST /log-repro-object/_doc
{ "log": { "ts": "2026-07-06T10:00:00Z" }, "path": "/a" }

POST /log-repro-scalar/_doc
{ "log": "plain string log line", "path": "/b" }

POST /_plugins/_ppl
{ "query": "source = log-repro-* | dedup path" }

Start by reading MergeRuleHelper and its DeepMergeRule, TextKeywordConflictRule, and LatestRule implementations, then trace OpenSearchExprValueFactory and ObjectContent through the reported parsing path. Compare how schema conflicts and per-document mismatches are handled today. Done requires an agreed policy and defined behavior for both layers, including how any configurable modes should be specified and tested.