Validate api_type matches path in ClusterMetricsInput

[manaswini1920]

Description

When creating a cluster metrics monitor, the api_type field was never parsed in ClusterMetricsInput.parseInner() — the user-provided value is ignored entirely. The clusterMetricType is always derived from the path via findApiType(constructedUri. path) in the init block. This allowed creating monitors with mismatched api_type and path fields (e.g., user sends api_type: CLUSTER_STATS with path: /_cat/indices, but CAT_INDICES is derived from the path). These malformed monitors could no
t be deleted via the DeleteMonitor API, failing with "The provided URL and URI fields form different URLs."

Added validation in parseInner to parse the api_type field and reject requests where the provided api_type does not match the type derived from the path.

Testing

Before fix — monitor created successfully. User-provided api_type is ignored, type is derived from path instead:
json

POST plugins/alerting/monitors                                                                                                                                                                                                                                
// api_type: CLUSTER_STATS, path: /_cat/indices/*?format=json&bytes=b                                                                                                                                                                                         
                                                                                                                                                                                                                                                              
Response: 200 OK — api_type stored as CAT_INDICES (derived from path, user input ignored)                                                                                                                                                                     
                                                                                                                                                                                                                                                              
// Attempting to delete fails:                                                                                                                                                                                                                                
DELETE plugins/alerting/monitors/<monitor_id>                                                                                                                                                                                                                 
{ "error": { "reason": "The provided URL and URI fields form different URLs." }, "status": 400 }                                                                                                                                                              

After fix — monitor creation rejected with clear error:
json

POST plugins/alerting/monitors                                                                                                                                                                                                                                
// Same request                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                              
Response: 400 Bad Request                                                                                                                                                                                                                                     
{ "error": { "reason": "The provided api_type [CLUSTER_STATS] does not match the path [/_cat/indices/*?format=json&bytes=b]." }, "status": 400 }                                                                                                              

Related Issues

Resolves opensearch-project/alerting#1987

Check List

• [X ] New functionality includes testing.
• New functionality has been documented.
• API changes companion pull request created.
• [X ] Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[toepkerd]

Code change looks good to me. In your failure case example above, user passes in api_type=CLUSTER_STATS, then it is silently changed to api_type=CAT_INDICES. Do we know where that silent change happens? Appears at first glance to be a fallback to some default value.

[manaswini1920]

Code change looks good to me. In your failure case example above, user passes in api_type=CLUSTER_STATS, then it is silently changed to api_type=CAT_INDICES. Do we know where that silent change happens? Appears at first glance to be a fallback to some default value.

│ Good catch on the wording — there's no silent change or fallback happening. The api_type field was never parsed in parseInner(), so the user-provided value is ignored entirely. The clusterMetricType is always derived from the path via findApiType(constructedUri.path) in the init block (line 72). So when the monitor is serialized back via toXContent, it writes the derived type (CAT_INDICES) rather than what the user sent (CLUSTER_STATS). I'll update the PR description to clarify this.