fix(opensearch): use direct HEAD check in indexExists(), guard null cih in clearIndex()

[fabrizzio-dotCMS]

Summary

• Replace listIndices()-based indexExists() with a DB-first check via IndiciesAPI.loadIndicies() — vendor-neutral, no ES/OS client dependency
• Normalize index name to logical form before getClusterHealth() lookup in clearIndex() to prevent NPE when a physical name is passed
• Add null-guard on cih with a clear DotStateException message
• Fix integration test that checked clusterIndexName twice instead of covering both logical and physical name variants

Root cause

ESIndexAPI.indexExists() used listIndices() which builds an ES wildcard query from IndexType.getPattern(). That pattern embeds ClusterFactory.getClusterId(), which reads from the dot_cluster DB table first. When the DB cluster ID diverges from DOT_DOTCMS_CLUSTER_ID (e.g. stale DB row, or the env var was added after first startup), the pattern matches no indices. getIndices() catches the empty result and swallows it, so listIndices() silently returns an empty set → indexExists() always returns false → clearIndex() throws HTTP 400 before the operation executes.

Fix

Query the indicies DB table first via APILocator.getIndiciesAPI().loadIndicies(). The stored physical names carry the cluster prefix that was real at activation time — immune to any DB/env-var cluster-ID mismatch. Falls back to the existing listIndices() ES scan for indices not yet tracked in the DB (bootstrap, direct createIndex calls, integration tests).

Test plan

• Build: ./mvnw install -pl :dotcms-core -DskipTests
• Integration test: ESIndexAPITest#index_exists_should_resolve_even_with_cluster_id
• QA: PUT /api/v1/esindex/{indexName}?action=clear with DOT_DOTCMS_CLUSTER_ID set → expect HTTP 200 and index recreated

Closes #35303

🤖 Generated with Claude Code

[claude]

Claude finished @fabrizzio-dotCMS's task in 2m 48s —— View job

---

PR Review

• Gather context
• Read changed files
• Analyze implementation
• Post review

---

The root-cause analysis and overall approach are sound. Four issues worth addressing:

---

1. Double listIndices() in Phase 2 — two ES round trips (ESIndexAPI.java:426)

// current — hits ES twice
return listIndices().contains(stripped) || listIndices().contains(indexName.toLowerCase());

listIndices() performs a full ES cluster scan each time. Should be one call:

final Set<String> all = listIndices();
return all.contains(stripped) || all.contains(indexName.toLowerCase());

Fix this →

---

2. Phase 2 second condition is dead code (ESIndexAPI.java:426)

listIndices() returns logical names — the cluster prefix is always stripped in getIndices(). So listIndices().contains(indexName.toLowerCase()) can never be true when indexName is a physical name (it would need to contain the prefix). When indexName is already logical, stripped == indexName.toLowerCase() and the second condition duplicates the first. This looks like a carry-over from the old two-check pattern that no longer makes sense after introducing stripped. Worth removing or documenting why it's needed.

---

3. Missing .toLowerCase() in clearIndex() logical-name lookup (ESIndexAPI.java:468)

final String logicalName = removeClusterIdFromName(indexName);  // no toLowerCase()
final ClusterIndexHealth cih = getClusterHealth().get(logicalName);

getClusterHealth() keys are lowercase logical names (ES enforces lowercase; the map uses removeClusterIdFromName(x.getKey())). If indexName arrives with any uppercase characters, the lookup silently misses, cih is null, and the new guard throws a 400 with the misleading message "health data is unavailable" — even though the index exists. indexExists() gets this right at line 407 with indexName.toLowerCase(). Should be:

final String logicalName = removeClusterIdFromName(indexName.toLowerCase());

Fix this →

---

4. Test covers Phase 2 (ES scan) only, not the Phase 1 (DB) path (ESIndexAPITest.java:73)

createIndex() does not register the index in the indicies DB table — only activateIndex() does. So indexExists() in this test always falls through to Phase 2. The cluster-ID mismatch scenario described in the root cause (DB record exists but cluster ID diverges from env var) is untested. The test name index_exists_should_resolve_even_with_cluster_id implies otherwise. Not a blocker, but the test doesn't actually exercise the fixed code path.

---

Minor — pre-existing issue, not introduced here (ESIndexAPI.java:613): updateReplicas() calls getClusterHealth().get(getNameWithClusterIDPrefix(indexName)), but getClusterHealth() maps by logical names (it strips the prefix in the collector). The lookup always misses and health is always null, silently skipping the replica update. Unrelated to this PR but in the same area.