[BUG] Doc-level monitor percolate fails with strict_dynamic_mapping_exception when the source index has an array of objects under a dynamic: strict object #2299

Describe the bug

A doc-level monitor fails on every run with Failed to run percolate search when the source index has an array of objects under an object mapped with dynamic: strict. The document-side and mapping-side field renaming treat arrays of objects differently, and the plugin copies the source object's dynamic: strict into the queries index.

Error (from .opensearch-alerting-queries-000001):

StrictDynamicMappingException[mapping set to strict, dynamic introduction of
[related_incidents_incidents_<monitorId>] within [unmapped.platform] is not allowed]

Cause (from reading 3.8.0.0)

1. DocLevelMonitorQueries.traverseMappingsAndUpdate (DocLevelMonitorQueries.kt, lines 217-254) recurses into object nodes that have properties and renames only leaf fields to <leaf>_<index>_<monitorId>. For related_incidents (an object with properties), the children are renamed (incident_<index>_<id>, rule_<index>_<id>, and so on).
2. TransportDocLevelMonitorFanOutAction.transformDocumentFieldNames (lines 1198-1233) recurses only when entry.value is Map<*, *>. An array of objects is a List, so it is treated as a leaf and the key itself is renamed to related_incidents_<index>_<id>.
3. The queries-index mapping has the renamed children under related_incidents, but the percolated document has a different field, related_incidents_<index>_<id>, as a sibling in the parent object.
4. The traversal never resets dynamic. A dynamic: strict on an object in the source mapping is copied into the queries index. The plugin's own base mapping (doc-level-queries.json) is not strict. So parsing the renamed document copy is rejected.

Objects at the root level are not affected, because only properties is copied from the source mapping and the root dynamic is dropped.

To reproduce

Derived from the code and from logs on a real cluster; I have not yet run these exact steps on a clean cluster.

1. Create an index with dynamic: strict on an object that contains an array of objects:

   PUT my-index
   {"mappings":{"properties":{"platform":{"dynamic":"strict","properties":{
     "series":{"type":"keyword"},
     "related":{"properties":{"id":{"type":"keyword"},"count":{"type":"integer"}}}}}}}}
   

2. Create a doc-level monitor on my-index with any query, for example series:abc.
3. Index a document with the array populated:

   POST my-index/_doc
   {"platform":{"series":"abc","related":[{"id":"x","count":1}]}}
   

4. Wait for the monitor to run.

Expected: the document is percolated against the queries.
Actual: the run fails with the exception above and an error alert is written.

Observed on

OpenSearch 3.8.0 with alerting 3.8.0.0. The two files above are identical in 3.9.0.0, and the is Map<*, *> check in transformDocumentFieldNames is unchanged on main. The failing monitor's own query did not reference the array field.

Suggested fix

Make the two sides consistent. Either:

• recurse into List values of maps in transformDocumentFieldNames so array elements are renamed like the mapping side, or
• drop dynamic from the object nodes copied into the queries index.

Related

#2157 (alias-type fields break upsertQueryIndex) is a different failure with a similar cause: the mapping copy does not account for some source mapping features.