fix(prometheus): handle /api/v1/metadata responses without data field

[lezzago]

Description

PrometheusClientImpl blindly called response.getJSONObject("data") / response.getJSONArray("data") on every Prometheus API response. The Prometheus HTTP API spec does not mandate that data be present, and Cortex (observed on v1.18.1) legitimately returns {"status":"success"} with no data key when the endpoint has nothing to report.

This is the default state for any Cortex backend fed via OTLP remote-write, since OTLP metrics carry no OpenMetrics # HELP / # TYPE comments for Cortex to surface. A vanilla Prometheus returns {"status":"success","data":{}} in the same state, so the spec allows both shapes.

The resulting JSONException propagates up through PrometheusQueryHandler.getResources() → DirectQueryExecutorServiceImpl and surfaces in OpenSearch Dashboards' Metrics Explore UI as "Unable to load metrics" for every metric against any Cortex-backed Prometheus datasource.

Stack trace observed on the live EKS deployment:

org.json.JSONException: JSONObject["data"] not found.
    at org.json.JSONObject.get(JSONObject.java:568)
    at org.json.JSONObject.getJSONObject(JSONObject.java:778)
    at org.opensearch.sql.prometheus.client.PrometheusClientImpl.getAllMetrics(PrometheusClientImpl.java:200)
    at org.opensearch.sql.prometheus.query.PrometheusQueryHandler.getResources(PrometheusQueryHandler.java:136)
    ...

Fix

Guard each affected call site (getAllMetrics, queryRange, query, getLabels, getLabel, getSeries, queryExemplars, getAlerts) with a response.has("data") check, returning a type-appropriate empty value (new JSONObject(), new JSONArray(), new ArrayList<>(), new HashMap<>()) instead of throwing.

Mutable empty collections are intentional: the transport layer reflectively constructs response maps, and Collections.emptyMap() / Collections.emptyList() trigger InaccessibleObjectException ("module java.base does not 'opens java.util' to unnamed module") during XContent serialization.

getRules already routes through normalizeRulesResponse(), which handles the missing-data case, so no change was needed there. Alertmanager methods don't read a data field.

Testing

• ./gradlew :direct-query-core:test — 254 tests, 0 failures (including 9 new tests — one per patched method — each feeding {"status":"success"} and asserting a safe empty return).
• ./gradlew :prometheus:test — 104 tests, 0 failures.
• End-to-end validation against a live Cortex v1.18.1 backend in Docker:
  • Direct REST: GET /_plugins/_directquery/_resources/<ds>/api/v1/metadata → HTTP 200 {"data":{}} (was 500).
  • OpenSearch Dashboards Metrics Explore UI: loads fully with label breakdowns, no "Unable to load metrics" toast.
  • Dashboards POST /api/enhancements/resources for metric_metadata → 200 {"data":{},"type":"prometheus"} (was 503).

Issues resolved

N/A — filed directly.

Check List

• New functionality includes testing.
• New functionality has been documented.
• 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.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[joshuali925]

do we need changelog now?