Skip to content

fix(os-index): resolve getIndexDocumentCount physical name via the read provider (.os tag) (#36501)#36558

Open
fabrizzio-dotCMS wants to merge 1 commit into
mainfrom
issue-36501-os-indexdoccount-naming
Open

fix(os-index): resolve getIndexDocumentCount physical name via the read provider (.os tag) (#36501)#36558
fabrizzio-dotCMS wants to merge 1 commit into
mainfrom
issue-36501-os-indexdoccount-naming

Conversation

@fabrizzio-dotCMS

Copy link
Copy Markdown
Member

Proposed Changes

ContentletIndexAPIImpl.getIndexDocumentCount(String) resolved the physical name with getNameWithClusterIDPrefix (cluster prefix but no .os tag). Under ES→OS migration phase 2/3 the read provider is OpenSearch, whose indices are .os-tagged, so the lookup hit a non-existent index and threw. Now resolves via the read provider's own toPhysicalName() (ES: prefix only; OS: prefix + .os), mirroring the sibling getIndexDocumentCount(String, IndexTag) overload. Contributes to #36501.

Verification

Phase 2, isolated env: ContentletIndexAPIImplTest#testGetIndexDocumentCountSuccess 1/0/0 (previously failing).

Refs #36501, #36320.

…ad provider (.os tag) (#36501)

ContentletIndexAPIImpl.getIndexDocumentCount(String) resolved the physical index
name with indexAPI.getNameWithClusterIDPrefix(indexName), which adds the cluster
prefix but NOT the .os tag. Under migration phase 2/3 the read provider is
OpenSearch, whose indices are .os-tagged, so the lookup hit a non-existent index
("no such index [cluster_....working_...]" without the .os suffix) and threw.

Resolve the physical name through the read provider's own toPhysicalName() — which
adds the cluster prefix for ES and the prefix + .os tag for OS — mirroring the
sibling getIndexDocumentCount(String, IndexTag) overload. (Fixes
ContentletIndexAPIImplTest.testGetIndexDocumentCountSuccess under phase 2.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@claude

claude Bot commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

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


Rollback-Safety Analysis

  • Read docs/core/ROLLBACK_UNSAFE_CATEGORIES.md
  • Reviewed the PR diff (ContentletIndexAPIImpl.java, +5/-2)
  • Checked against all unsafe categories (C-1..4, H-1..8, M-1..4)
  • Verdict posted

Verdict: Safe to roll back. No unsafe category applies.

The change only affects ContentletIndexAPIImpl.getIndexDocumentCount(String), swapping indexAPI.getNameWithClusterIDPrefix(indexName) for readProvider.toPhysicalName(indexName) when resolving the physical index name to query for a document count. It's a pure in-memory string-resolution fix:

  • No DB schema/migration changes, no runonce tasks
  • No ES/OS mapping changes (putMapping, ESMappingAPIImpl, etc. untouched)
  • No data transformation/backfill, no renames, no PK/constraint changes
  • No REST/GraphQL contract change, no OSGi-exported interface signature change (ContentletIndexAPI interface itself is untouched — this is a private-method change to an internal impl)
  • No VTL viewtool contract change

If rolled back, N-1 simply reverts to the old (buggy) prefix-resolution behavior for this one internal helper — no persisted state, index mapping, or API contract is affected either way.

Label AI: Safe To Rollback has been applied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI: Safe To Rollback Area : Backend PR changes Java/Maven backend code

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant