Fix: Skip alias-type fields in doc-level monitor query index mapping

[thecodingshrimp]

Fix: Skip alias-type fields in doc-level monitor query index mapping

Related issue

Fixes: #2157

---

Summary

DocLevelMonitorQueries.upsertQueryIndex fails with HTTP 500 whenever a source index contains fields with "type": "alias". This PR adds a two-line guard in leafNodeProcessor that skips alias fields during mapping traversal, preventing invalid PUT _mapping calls to the percolate query index.

The fix is minimal and surgical: it does not change how any other field type is handled.

---

Root cause

File: alerting/src/main/kotlin/org/opensearch/alerting/util/DocLevelMonitorQueries.kt
Function: leafNodeProcessor

When upsertQueryIndex builds the query index mappings it calls traverseMappingsAndUpdate, which recursively walks every leaf field of every source index and delegates to leafNodeProcessor. For each leaf, leafNodeProcessor rewrites field names and the alias path value by appending _<indexName>_<monitorId> to produce a per-monitor suffix. For type: alias fields this produces a synthesized path that does not exist as a concrete field in the query index. OpenSearch then rejects the PUT _mapping call:

Invalid [path] value [<originalPath>_<backingIndexName>_<monitorId>] for field alias [...]:
an alias must refer to an existing field in the mappings.

The percolate query index (.opensearch-alerting-queries-*) stores query_string queries, not documents. Alias resolution is not used during percolate matching. Alias fields copied to the query index therefore serve no semantic purpose — they are index-local contracts that are only meaningful in the context of the index where they are defined.

The plugin is not idempotent: alias fields left in a source index by a prior monitor lifecycle are re-discovered on every subsequent upsertQueryIndex call and trigger the same failure. The deleteQueryIndexInEveryRun=true retry path does not escape this because the same source mappings produce the same invalid synthesized path on retry.

---

Changes

alerting/src/main/kotlin/org/opensearch/alerting/util/DocLevelMonitorQueries.kt

1. leafNodeProcessor — early return for alias fields.
   Add a guard before the existing val newProps = props.toMutableMap() line. When props["type"] == "alias", return a triple with an empty mutableMapOf() as the properties value. This signals the accumulation loop that the field should be excluded from updatedProperties.

   // Guard added at entry of leafNodeProcessor:
   if (props["type"] == "alias") {
       return Triple(fieldName, fieldName, mutableMapOf())
   }

2. traverseMappingsAndUpdate / properties.forEach accumulation loop — skip empty property maps.
   After calling leafNodeProcessor, check whether the returned properties map is empty. If it is, do not write an entry to updatedProperties. This prevents a zero-property alias stub from being submitted in the PUT _mapping body.

   // In the forEach loop that builds updatedProperties:
   val (newKey, _, newProps) = leafNodeProcessor(...)
   if (newProps.isNotEmpty()) {
       updatedProperties[newKey] = newProps
   }

These two changes together ensure that alias fields never appear in the PUT _mapping request body sent to the query index.

No changes to any public API, monitor data model, or query execution path. The query index schema for all non-alias field types is unaffected.

---

Testing notes

1. Unit test — alias field excluded from query index mappings.
   Create a MappingMetadata fixture that includes a type: alias field alongside a concrete keyword field. Assert that after traverseMappingsAndUpdate the returned map contains the concrete field and does not contain the alias field.

2. Integration test — monitor creation succeeds on index with alias fields.

   • Create an index with at least one type: alias field and one concrete field.
   • Create a doc-level monitor targeting that index.
   • Assert monitor creation returns HTTP 200 and monitor status is ACTIVE.
   • Verify the query index (.opensearch-alerting-queries-*) mapping does not contain any field with "type": "alias".

3. Regression test — idempotency across delete/re-create cycle.

   • Create a doc-level monitor, delete it, and re-create it against the same index.
   • Assert the second creation succeeds (HTTP 200) with no PUT _mapping 500 error in logs.

4. Existing test suite.
   Run the full DocLevelMonitorQueries test class and the doc-level monitor integration tests. No existing test should regress: the guard only affects fields with "type": "alias", which the existing tests do not exercise.

---

Out of scope

The SA plugin (opensearch-project/security-analytics) writes type: alias fields to backing indices on detector creation and does not remove them on detector deletion. That cleanup is tracked separately. This PR makes the alerting plugin resilient to alias fields regardless of their origin, which addresses the immediate breakage independently of when the SA cleanup lands.