[BUG] DELETE /api/v1/esindex/{name} does not clean up indicies table — orphaned DB rows

[fabrizzio-dotCMS]

Summary

DELETE /api/v1/esindex/{indexName} physically removes the index from the search provider (ES or OS) but does not delete the corresponding row from the indicies database table.

After deletion, the indicies table retains stale entries pointing to non-existent indices.

Observed behavior

1. DELETE /api/v1/esindex/working_20260414033602 → HTTP 200, index physically deleted from OS
2. SELECT * FROM indicies; → row working_20260414033602 still present
3. On next startup: dotCMS attempts to activate a non-existent index → potential startup failure or silent inconsistency

Affected providers

Confirmed for both ES and OS providers across all phases.

Root cause

ContentletIndexAPIImpl.delete() calls the physical delete on the search provider but does not follow up with a call to IndiciesAPI.removeIndiciesByName() (or equivalent) to remove the DB record.

Fix

After successful physical index deletion in ContentletIndexAPIImpl.delete(), delete the corresponding row from the indicies table:

// After successful physical delete:
APILocator.getIndiciesAPI().removeIndiciesByName(indexName);
// or for versioned indices:
versionedIndicesAPI.removeIndicesByName(indexName);

Ensure the cleanup handles both legacyIndiciesAPI (ES, non-versioned) and versionedIndicesAPI (OS, versioned) stores.

Discovered via

QA test run — TC-06 (Phase 3) and DELETE operations across phases, dotcms/dotcms:latest with single-node-os-migration stack.

Related

• Refs [TASK] Migrate ESMappingAPIImpl #34933
• PR task(Migrate ESMappingAPIImpl) Refs #34933 #35289

[github-actions]

PRs linked to this issue

• fix(index): clean up indicies DB rows on all physical delete paths by @fabrizzio-dotCMS