[analytics-engine] Strip AE-unsupported fields from test data and exclude the ITs doomed by it

[mengweieric]

Problem

On the analytics-engine route (-Dtests.analytics.parquet_indices=true), a test dataset whose mapping contains a field type the parquet/composite store can't handle (nested, geo_point, geo_shape, alias, or a store-disabled binary) fails index creation / ingestion. The failure surfaces later as an unrelated expected:<1> but was:<0> in a downstream IT rather than at the offending index/field — masking real assertions.

Fix

1. Strip unsupported-typed fields at load time — gated on tests.analytics.parquet_indices; a byte-for-byte no-op off the AE route.

• createIndexByRestClient removes unsupported {nested, geo_point, geo_shape, alias} properties recursively and reports the exact dropped paths (e.g. [location, point]), not just top-level names.
• loadIndex passes those paths to loadDataByRestClient, which strips each path from every bulk source doc recursively — through objects and arrays of objects — preserving siblings (location.city etc.), so mapping and data agree. Untouched docs stay byte-for-byte verbatim.
• loadDataByRestClient now fails loudly on bulk errors=true (names the index + first item errors), for all loads — silent partial ingestion no longer slips through a 200.
• The trigger is the mapping's field types, not the test's identity, so any IT — existing or newly added — loading such a dataset is handled out of the box. No per-index variant files. UNSUPPORTED_FIELD_TYPES is the single source of truth, imported by the verifier so the two can't drift.

binary is conditional: kept when store: true (engine reads it as VARBINARY), but stripped when store: false — the parquet store can't create a store-disabled binary field (Unable to derive source for [X] with store disabled, confirmed on the AE cluster).

2. Physically exclude PPL ITs doomed by the strip — a test whose query references a stripped field can never pass once that field is gone, so excluding it is correct, not a workaround. Centralized in integ-test/build.gradle, gated on the parsed analyticsEnabled boolean (so =false excludes nothing), method-level wherever possible so the rest of each class still runs. Verified field-by-field against the index mappings:

Excluded	Reason	Level
GeoPointFormatsIT	every test reads a geo_point field	class
DataTypeIT.test_nonnumeric_data_types	asserts nested_value + geo_point_value	method
DataTypeIT.test_alias_data_type	where alias_col (type: alias)	method
SystemFunctionIT.typeof_opensearch_types	typeof(geo_point_value)	method

Kept running (verified not doomed): GeoIpFunctionsIT (geoip() over text ip/name), StatsCommandIT.testStatsNested* (nested function calls, not a nested field), ConvertCommandIT/TrendlineCommandIT/ExplainIT alias usages (query result aliases, not alias-typed fields).

Verification

Verified locally — CI's integTest jobs run the legacy/default route (no tests.analytics.parquet_indices), so they never exercise this code; the AE route needs a force-routed 9-plugin cluster CI doesn't spin up.

Goal achieved (AE route, force-routed cluster, _explain confirmed LogicalTableScan(table=[[opensearch = real AE, not Calcite fallback):

• AnalyticsUnsupportedFieldStripVerifyIT passes over every Index dataset — per dataset it forces a clean reload, then asserts: clean live mapping, no stripped path left in sampled _source, and doc-count == source-doc count. (1 dataset, DATASOURCES, logs a transparent skip of the count leg only — its count query touches a system index; legs 1–3 still ran.)
• This is the fix proving itself: the verifier caught the binary store:false case, which the conditional strip now handles.

Unit (pure-logic, no cluster) — AnalyticsFieldStripTests 7/7: recursive path strip, complex_geo-shape (location.point removed, siblings kept, deep nested_locations.primary.office), arrays of objects, byte-identity of untouched docs, binary store-conditional, no-op-when-disabled.

No regression when AE is off (the v2/v3 path): strip code early-returns on !isEnabled() (mapping/data byte-identical); excludes are gated on the parsed analyticsEnabled. Confirmed empirically — ran StatsCommandIT/DataTypeIT/FieldsCommandIT/SearchCommandIT legacy (no parquet flag): 123 pass / 0 fail, and the new bulk-error check never tripped.

Check List

• New functionality includes testing.
• Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit f649962)

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Possible Issue The liveDocCountOrNull method catches all exceptions and returns null, which causes the test to skip doc-count verification even when the failure is unrelated to the strip logic (e.g., a genuine ingestion problem). This masks real issues. The method should only catch and return null for specific, known-safe exceptions (like shard-level count failures on system indices), not all exceptions. private Integer liveDocCountOrNull(String indexName) { String query = String.format("source=%s | stats count() as c", indexName); try { JSONObject result = executeQuery(query); return result.getJSONArray("datarows").getJSONArray(0).getInt(0); } catch (Exception e) { // The count query can fail for cluster-side reasons unrelated to the strip (e.g. it touches a // parquet-backed system index that can't serve a shard-level count). Don't let that mask the // strip proof — return null so the caller records a transparent skip. LOG.info("count query failed for [{}]: {}", indexName, rootMessage(e)); return null; } Possible Issue The stripBulkFields method splits on newline with limit -1 but then iterates i < lines.length - 1 when appending newlines. If the input ends with a newline, split("\n", -1) produces a trailing empty string, and the loop skips appending a newline after the second-to-last line, corrupting the output. The condition should be i < lines.length (always append newline) or the split should use a positive limit. if (i < lines.length - 1) { out.append('\n'); } } Possible Issue The failIfBulkHadItemErrors method iterates over action.keySet() (the bulk operation names like "index", "create") but does not break after processing the first key. If a single item somehow has multiple operation keys (malformed response), the method would add duplicate error entries for the same doc. Add a break after processing the first key. for (String op : action.keySet()) { JSONObject result = action.optJSONObject(op); if (result != null && result.has("error")) { firstErrors.add("doc#" + i + ": " + result.get("error")); } } }

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to f649962

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use .equals() for Integer comparison The comparison actualDocs != expectedDocs uses reference inequality on Integer objects. For values outside the cached range (-128 to 127), this may fail even when the numeric values are equal. Use .equals() or unbox to primitive int for correct numeric comparison. integ-test/src/test/java/org/opensearch/sql/calcite/remote/AnalyticsUnsupportedFieldStripVerifyIT.java [157-172] Integer actualDocs = liveDocCountOrNull(name); if (actualDocs == null) { skippedDocCount.add(index.name() + " (count query errored — see Legs 1-3 + bulk check)"); -} else if (actualDocs != expectedDocs) { +} else if (!actualDocs.equals(expectedDocs)) { failures.add( "[" + index.name() + " -> " + name + "] ingested " + actualDocs + " docs but dataset" + " has " + expectedDocs + " (partial/failed ingestion)"); } Suggestion importance[1-10]: 8 __ Why: Using != for Integer comparison can fail for values outside the cached range (-128 to 127) due to reference inequality. This is a potential bug that could cause incorrect test failures. Using .equals() ensures correct numeric comparison.	Medium
General	Skip recursion after field removal After removing a field from properties, the method continues to recurse into nested properties. If the removed field had nested properties, the recursion should be skipped since the entire subtree is dropped. Add an early continue after removal to avoid processing a removed field's children. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [232-248] private static void collectAndRemoveUnsupported( JSONObject properties, List<String> prefix, Set<List<String>> dropped) { for (String field : properties.keySet().toArray(new String[0])) { JSONObject def = properties.optJSONObject(field); if (def == null) { continue; } List<String> path = new ArrayList<>(prefix); path.add(field); if (isUnsupportedForAeStore(def)) { properties.remove(field); dropped.add(List.copyOf(path)); - } else if (def.has("properties")) { + continue; + } + if (def.has("properties")) { collectAndRemoveUnsupported(def.getJSONObject("properties"), path, dropped); } } } Suggestion importance[1-10]: 3 __ Why: The suggestion is technically correct but has minimal impact. The current code uses else if which already prevents recursion after removal. Adding an explicit continue after removal would make the logic clearer but doesn't fix a bug since the else if already handles this case.	Low

---

Previous suggestions

Suggestions up to commit ab4e7c6

Category	Suggestion	Impact
General	Avoid loading entire file into memory The method loads the entire dataset file into memory as a single string, which can cause OutOfMemoryError for large test datasets. Use a streaming approach with BufferedReader to process lines incrementally instead of loading the entire file at once. integ-test/src/test/java/org/opensearch/sql/calcite/remote/AnalyticsUnsupportedFieldStripVerifyIT.java [320-340] private static int sourceDocCount(Index index) throws IOException { String dataSet = index.getDataSet(); if (dataSet == null || dataSet.isEmpty()) { return 0; } - String body = new String(Files.readAllBytes(Paths.get(getResourceFilePath(dataSet)))); int docs = 0; - for (String line : body.split("\n", -1)) { - String trimmed = line.trim(); - if (trimmed.isEmpty() || trimmed.charAt(0) != '{') { - continue; - } - JSONObject obj = new JSONObject(trimmed); - boolean isActionLine = - obj.has("index") || obj.has("create") || obj.has("update") || obj.has("delete"); - if (!isActionLine) { - docs++; + try (BufferedReader reader = Files.newBufferedReader(Paths.get(getResourceFilePath(dataSet)))) { + String line; + while ((line = reader.readLine()) != null) { + String trimmed = line.trim(); + if (trimmed.isEmpty() || trimmed.charAt(0) != '{') { + continue; + } + JSONObject obj = new JSONObject(trimmed); + boolean isActionLine = + obj.has("index") || obj.has("create") || obj.has("update") || obj.has("delete"); + if (!isActionLine) { + docs++; + } } } return docs; } Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a memory efficiency issue where sourceDocCount loads entire dataset files into memory. Using BufferedReader for line-by-line processing is a valid improvement for large files, though test datasets are typically small, limiting the practical impact.	Low
	Add file size validation check Loading the entire dataset file into memory can cause OutOfMemoryError for large test datasets. Consider processing the file in chunks or streaming the data to avoid memory issues with large bulk payloads. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [435-447] public static void loadDataByRestClient( RestClient client, String indexName, String dataSetFilePath, Set<List<String>> droppedPaths) throws IOException { Path path = Paths.get(getResourceFilePath(dataSetFilePath)); + long fileSize = Files.size(path); + if (fileSize > 100 * 1024 * 1024) { // 100MB threshold + throw new IllegalArgumentException("Dataset file too large: " + fileSize + " bytes. Consider splitting the dataset."); + } String body = new String(Files.readAllBytes(path)); body = AnalyticsIndexConfig.stripBulkFields(body, droppedPaths); Request request = new Request( "POST", "/" + indexName + "/_bulk?" + AnalyticsIndexConfig.bulkLoadRefreshParam()); request.setJsonEntity(body); Response response = performRequest(client, request); failIfBulkHadItemErrors(indexName, response); } Suggestion importance[1-10]: 5 __ Why: Adding a file size check before loading is a reasonable safeguard against OutOfMemoryError with large datasets. However, the hardcoded 100MB threshold is arbitrary and may not suit all scenarios. The suggestion provides defensive validation but doesn't fundamentally solve the memory issue for files near the limit.	Low
	Prevent stack overflow in recursion The recursive method lacks depth limit protection, which could cause StackOverflowError on deeply nested JSON structures or circular references. Add a maximum recursion depth check to prevent stack exhaustion. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [302-325] +private static final int MAX_RECURSION_DEPTH = 100; + private static boolean removePath(Object node, List<String> path, int idx) { + if (idx >= MAX_RECURSION_DEPTH) { + throw new IllegalStateException("Maximum recursion depth exceeded while removing path"); + } String part = path.get(idx); boolean last = idx == path.size() - 1; boolean removed = false; if (node instanceof JSONObject) { JSONObject obj = (JSONObject) node; if (!obj.has(part)) { return false; } if (last) { obj.remove(part); return true; } removed = removePath(obj.get(part), path, idx + 1); } else if (node instanceof JSONArray) { ... } return removed; } Suggestion importance[1-10]: 4 __ Why: While adding recursion depth protection is a defensive practice, the removePath method's recursion depth is bounded by the path length (typically shallow in JSON mappings). The risk of StackOverflowError is low in practice, making this a minor defensive improvement rather than addressing a likely issue.	Low

Suggestions up to commit efdcc7e

Category	Suggestion	Impact
General	Use explicit list for iteration The recursive call to removeIfUnsupported modifies the sub object while iterating over its keys. Converting keySet() to an array avoids ConcurrentModificationException, but this pattern is fragile. Use an explicit list copy for clarity and maintainability. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [208-225] private static boolean removeIfUnsupported(JSONObject properties, String field) { JSONObject def = properties.optJSONObject(field); if (def == null) { return false; } String type = def.optString("type", null); if (type != null && UNSUPPORTED_FIELD_TYPES.contains(type)) { properties.remove(field); return true; } if (def.has("properties")) { JSONObject sub = def.getJSONObject("properties"); - for (String child : sub.keySet().toArray(new String[0])) { + List<String> childKeys = new ArrayList<>(sub.keySet()); + for (String child : childKeys) { removeIfUnsupported(sub, child); } } return false; } Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that using new ArrayList<>(sub.keySet()) is clearer than sub.keySet().toArray(new String[0]) for avoiding ConcurrentModificationException during iteration. This improves code readability and maintainability, though both approaches are functionally correct.	Low
	Remove redundant null check The loop condition checks r.getCause() != r but also has a redundant if (r.getCause() == null) break; inside. The inner check is unnecessary since the loop condition already handles null causes. Remove the redundant break to simplify the logic. integ-test/src/test/java/org/opensearch/sql/calcite/remote/AnalyticsUnsupportedFieldStripVerifyIT.java [168-179] private static boolean isMissingDatasetFile(Throwable t) { - for (Throwable r = t; r != null && r.getCause() != r; r = r.getCause()) { + for (Throwable r = t; r != null && r.getCause() != null && r.getCause() != r; r = r.getCause()) { if (r instanceof java.nio.file.NoSuchFileException || r instanceof java.io.FileNotFoundException) { return true; - } - if (r.getCause() == null) { - break; } } return false; } Suggestion importance[1-10]: 4 __ Why: The suggestion correctly identifies a redundant null check in the loop. However, the improved code changes the loop condition rather than just removing the inner break statement, which is a valid but different approach. The impact is minor as both versions work correctly.	Low
	Optimize JSON parsing logic The method creates a JSONObject from every line that looks like JSON, even action lines that won't be modified. This is inefficient and could throw exceptions on malformed JSON. Parse the JSON only after confirming it's a source line that needs modification. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [238-272] static String stripBulkFields(String bulkBody, Set<String> droppedFields) { if (!isEnabled() || droppedFields.isEmpty()) { return bulkBody; } String[] lines = bulkBody.split("\n", -1); StringBuilder out = new StringBuilder(bulkBody.length()); for (int i = 0; i < lines.length; i++) { String line = lines[i]; String trimmed = line.trim(); - if (!trimmed.isEmpty() && trimmed.charAt(0) == '{') { + if (!trimmed.isEmpty() && trimmed.charAt(0) == '{' && i % 2 == 1) { JSONObject doc = new JSONObject(trimmed); - ... + boolean removedAny = false; + for (String f : droppedFields) { + if (doc.has(f)) { + doc.remove(f); + removedAny = true; + } + } + if (removedAny) { + line = doc.toString(); + } } out.append(line); if (i < lines.length - 1) { out.append('\n'); } } return out.toString(); } Suggestion importance[1-10]: 3 __ Why: The suggestion to use i % 2 == 1 to identify source lines is fragile and incorrect. Bulk format alternates action/source lines, but the current code correctly checks for action keys (index, create, etc.) which is more robust than relying on line position, especially if the bulk data has empty lines or formatting variations.	Low

Suggestions up to commit d076417

Category	Suggestion	Impact
General	Fix redundant loop termination logic The loop condition checks r.getCause() != r but then has a redundant break when r.getCause() == null. The loop will naturally terminate when r.getCause() is null because the next iteration's condition r != null will still be true but r.getCause() != r becomes meaningless. Remove the redundant null check and break statement. integ-test/src/test/java/org/opensearch/sql/calcite/remote/AnalyticsUnsupportedFieldStripVerifyIT.java [168-179] private static boolean isMissingDatasetFile(Throwable t) { - for (Throwable r = t; r != null && r.getCause() != r; r = r.getCause()) { + for (Throwable r = t; r != null && r.getCause() != null && r.getCause() != r; r = r.getCause()) { if (r instanceof java.nio.file.NoSuchFileException || r instanceof java.io.FileNotFoundException) { return true; - } - if (r.getCause() == null) { - break; } } return false; } Suggestion importance[1-10]: 4 __ Why: The suggestion correctly identifies redundant logic in the loop. However, the current code is functionally correct and the redundancy doesn't cause bugs. The improvement is minor - it simplifies the loop condition by removing the redundant break statement, making the code slightly cleaner.	Low

Suggestions up to commit 13d1081

Category	Suggestion	Impact
Possible issue	Verify array bounds before assertion The test assumes lines[3] contains the second document, but split("\n", -1) with a trailing newline creates an empty final element. This causes an off-by-one error where lines[3] is actually empty, not the second document. Verify the array indices match the actual split result. integ-test/src/test/java/org/opensearch/sql/legacy/AnalyticsFieldStripTests.java [109-127] @Test public void bulkStrip_leavesUntouchedSourceLinesByteForByte() { enable(); // doc1 carries a dropped key (gets rewritten); doc2 does not (must pass through verbatim). String docWithDrop = "{\"keep_text\":\"x\",\"nested_value\":[{\"a\":1}]}"; String docNoDrop = "{\"keep_text\":\"y\",\"age\": 30,\"z\":1}"; String bulk = "{\"index\":{\"_id\":\"1\"}}\n" + docWithDrop + "\n" + "{\"index\":{\"_id\":\"2\"}}\n" + docNoDrop + "\n"; String out = AnalyticsIndexConfig.stripBulkFields(bulk, Set.of("nested_value")); String[] lines = out.split("\n", -1); // The doc that had no dropped key is byte-for-byte identical (odd spacing/key order preserved). + assertTrue("Expected at least 5 lines", lines.length >= 5); assertEquals(docNoDrop, lines[3]); // The doc that had a dropped key lost it. assertFalse(new JSONObject(lines[1]).has("nested_value")); } Suggestion importance[1-10]: 3 __ Why: The suggestion identifies a potential off-by-one issue with array indexing after split("\n", -1) with a trailing newline. However, examining the test code shows the bulk string ends with "\n", and split("\n", -1) will create 5 elements (lines[0-4]), so lines[3] is valid. The suggestion adds a bounds check which is defensive but not strictly necessary given the controlled test input.	Low

Suggestions up to commit 812f87b

Category	Suggestion	Impact
Possible issue	Verify array bounds after split operation The test assumes lines[3] contains the second document, but split("\n", -1) with a trailing newline creates an empty string at lines[4]. The assertion assertEquals(docNoDrop, lines[3]) will fail because the actual document is at a different index. Verify the split behavior matches the bulk format structure. integ-test/src/test/java/org/opensearch/sql/legacy/AnalyticsFieldStripTests.java [109-127] @Test public void bulkStrip_leavesUntouchedSourceLinesByteForByte() { enable(); // doc1 carries a dropped key (gets rewritten); doc2 does not (must pass through verbatim). String docWithDrop = "{\"keep_text\":\"x\",\"nested_value\":[{\"a\":1}]}"; String docNoDrop = "{\"keep_text\":\"y\",\"age\": 30,\"z\":1}"; String bulk = "{\"index\":{\"_id\":\"1\"}}\n" + docWithDrop + "\n" + "{\"index\":{\"_id\":\"2\"}}\n" + docNoDrop + "\n"; String out = AnalyticsIndexConfig.stripBulkFields(bulk, Set.of("nested_value")); String[] lines = out.split("\n", -1); + // Verify we have the expected number of lines (4 content lines + 1 trailing empty) + assertEquals(5, lines.length); // The doc that had no dropped key is byte-for-byte identical (odd spacing/key order preserved). assertEquals(docNoDrop, lines[3]); // The doc that had a dropped key lost it. assertFalse(new JSONObject(lines[1]).has("nested_value")); } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that split("\n", -1) with a trailing newline creates an empty string at the end of the array. Adding a verification of the expected array length (5 elements) before accessing lines[3] improves test robustness and makes the test's assumptions explicit, preventing potential ArrayIndexOutOfBoundsException.	Medium
General	Handle malformed JSON gracefully Creating a JSONObject from every line that starts with { can throw JSONException for malformed JSON, causing the entire bulk load to fail. Add exception handling to skip or log malformed lines instead of propagating the exception, ensuring robustness during data ingestion. integ-test/src/test/java/org/opensearch/sql/legacy/TestUtils.java [238-272] static String stripBulkFields(String bulkBody, Set<String> droppedFields) { if (!isEnabled() || droppedFields.isEmpty()) { return bulkBody; } String[] lines = bulkBody.split("\n", -1); StringBuilder out = new StringBuilder(bulkBody.length()); for (int i = 0; i < lines.length; i++) { String line = lines[i]; String trimmed = line.trim(); if (!trimmed.isEmpty() && trimmed.charAt(0) == '{') { - JSONObject doc = new JSONObject(trimmed); - ... + try { + JSONObject doc = new JSONObject(trimmed); + ... + } catch (org.json.JSONException e) { + // Skip malformed JSON lines to prevent bulk load failure + out.append(line); + if (i < lines.length - 1) { + out.append('\n'); + } + continue; + } } out.append(line); if (i < lines.length - 1) { out.append('\n'); } } return out.toString(); } Suggestion importance[1-10]: 7 __ Why: Adding exception handling for JSONException when parsing bulk lines improves robustness. However, the suggestion asks to verify/ensure proper error handling rather than fixing a confirmed bug. The current code assumes well-formed test fixtures, but graceful handling of malformed JSON would prevent complete failure during data ingestion.	Medium

[github-actions]

Persistent review updated to latest commit 13d1081

[github-actions]

Persistent review updated to latest commit d076417

[github-actions]

Persistent review updated to latest commit efdcc7e

[mengweieric]

Failing CIs are unrelated to this PR

[dai-chen]

Is all our IT CI broken? Just wonder how to verify these changes..

[github-actions]

Persistent review updated to latest commit ab4e7c6

[mengweieric]

Is all our IT CI broken? Just wonder how to verify these changes..

we should fix the CIs besides this PR but I verified locally of

Run AnalyticsUnsupportedFieldStripVerifyIT on a force-routed AE cluster with -Dtests.analytics.parquet_indices=true. It loads every Index dataset through the real load path and asserts per dataset: clean mapping, no stripped path left in _source, doc count == source doc count. It passes, and fails loudly/attributably if any dataset still ingests an unsupported field, so it's the durable proof artifact in the PR.

Also: unit tests 7/7 (nested paths + arrays of objects), and legacy route with no parquet flag 123 pass / 0 fail so nothing regresses when AE is off.

[dai-chen]

I may miss it somewhere. Could you point me where we gate this by AE enabled setting?

[mengweieric]

the call site is intentionally unconditional, but the actual gate is inside AnalyticsIndexConfig

[dai-chen]

Is all our IT CI broken? Just wonder how to verify these changes..

we should fix the CIs besides this PR but I verified locally of

Run AnalyticsUnsupportedFieldStripVerifyIT on a force-routed AE cluster with -Dtests.analytics.parquet_indices=true. It loads every Index dataset through the real load path and asserts per dataset: clean mapping, no stripped path left in _source, doc count == source doc count. It passes, and fails loudly/attributably if any dataset still ingests an unsupported field, so it's the durable proof artifact in the PR.

Also: unit tests 7/7 (nested paths + arrays of objects), and legacy route with no parquet flag 123 pass / 0 fail so nothing regresses when AE is off.

I thought our CI is failing on dependency after version bump. But it seems due to this single test:

2026-06-11T22:45:47.0923183Z Tests with failures:
2026-06-11T22:45:47.0924323Z  - org.opensearch.sql.sql.QueryValidationIT.testAliasToKeywordMultiFieldFailsWithBadRequest

[mengweieric]

Is all our IT CI broken? Just wonder how to verify these changes..

we should fix the CIs besides this PR but I verified locally of
Run AnalyticsUnsupportedFieldStripVerifyIT on a force-routed AE cluster with -Dtests.analytics.parquet_indices=true. It loads every Index dataset through the real load path and asserts per dataset: clean mapping, no stripped path left in _source, doc count == source doc count. It passes, and fails loudly/attributably if any dataset still ingests an unsupported field, so it's the durable proof artifact in the PR.
Also: unit tests 7/7 (nested paths + arrays of objects), and legacy route with no parquet flag 123 pass / 0 fail so nothing regresses when AE is off.

I thought our CI is failing on dependency after version bump. But it seems due to this single test:

2026-06-11T22:45:47.0923183Z Tests with failures:
2026-06-11T22:45:47.0924323Z  - org.opensearch.sql.sql.QueryValidationIT.testAliasToKeywordMultiFieldFailsWithBadRequest

yea fixed in this PR: #5545

[github-actions]

Persistent review updated to latest commit f649962