fix(context-center): tolerate related entities whose type has no repository in the list path

[sonika-shah]

What & Why

The Context Center / Knowledge Center list endpoint — GET /v1/contextCenter/pages (formerly /v1/knowledgeCenter) — with fields=relatedEntities returns a 404 for the entire page when any single page has a related-entity relationship row whose type has no entity repository, e.g. a search-index-only pseudo-type such as tableColumn.

Observed in the logs as:

org.openmetadata.service.exception.EntityNotFoundException: Entity repository for tableColumn not found. Is the ENTITY_TYPE_MAP initialized?
  at org.openmetadata.service.Entity.getEntityRepository(Entity.java:...)
  ...

Root cause

The bulk setFields path resolves related entities in KnowledgePageRepository.resolveReferencesByType: it groups the HAS relationship rows by fromEntity type and calls Entity.getEntityReferencesByIds(type, …) per type. For a type with no repository, that reaches Entity.getEntityRepository(type) and throws EntityNotFoundException. A single stray relationship row therefore fails the whole list response.

The single-entity read path does not have this problem: EntityRelationshipRepository.getEntityReferences already catches and skips unresolvable types. The hand-rolled bulk resolver — and its byte-identical copy in ContextMemoryRepository — omitted that resilience.

How such a row exists: KnowledgePageRepository.prepare discards the stripped return of EntityUtil.populateEntityReferences, so a pseudo-type ref survives into storeRelationships and is persisted as a page --HAS--> <pseudo-type> row. It is then unresolvable on read.

Fix

Skip relationship rows whose type has no repository (Entity.hasEntityRepository) at grouping time, in both KnowledgePageRepository and ContextMemoryRepository. This mirrors the single-entity path's resilience. It is:

• self-maintaining — no hardcoded pseudo-type list;
• pagination-safe — relatedEntities is a nested per-page field, not the paginated collection, so skipping an unresolvable ref does not affect page counts/offsets.

Tests

Adds KnowledgePageHierarchyIT#testListToleratesRelatedEntityWithoutRepository: creates a page whose relatedEntities includes both a resolvable ref and one of a type with no repository, then lists with fields=relatedEntities and asserts the list returns 200 with the unresolvable ref skipped and the resolvable ref still present. This test fails (404) without the fix.

Manual reproduction

1. Create a Context Center page with a relatedEntities entry of { "id": <uuid>, "type": "tableColumn" }.
2. GET /v1/contextCenter/pages?fields=relatedEntities → 404 with the error above (before the fix); 200 with the pseudo-type entry skipped (after the fix).

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[gitar-bot]

Code Review ✅ Approved

Adds resilience to the list path in KnowledgePageRepository and ContextMemoryRepository to skip related entity types without a repository, preventing 404 errors on list requests. No issues found.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar | Powered by Gitar — free for open source}

[Copilot]

Pull request overview

This PR hardens the Context Center / Knowledge Center list path (GET /v1/contextCenter/pages?fields=relatedEntities) so it no longer fails the entire response when a page has a related-entity relationship pointing to an entity type without a registered repository (e.g., search-index-only pseudo-types like tableColumn). The change mirrors the single-entity read path’s behavior by skipping unresolvable relationship rows during bulk reference resolution.

Changes:

• Skip relationship rows for types that don’t have an entity repository during bulk related-entity resolution (prevents EntityNotFoundException → 404 for the whole list).
• Apply the same resilience in both KnowledgePageRepository and ContextMemoryRepository.
• Add an integration test that reproduces the failure and asserts the list response remains 200 while skipping only the unresolvable related entity.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/KnowledgePageRepository.java	Filters out relationship rows whose fromEntity type has no repository before calling getEntityReferencesByIds, preventing list-wide failure.
openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/ContextMemoryRepository.java	Applies the same repository-existence filter to the analogous bulk resolver to keep behavior consistent across the two implementations.
openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/KnowledgePageHierarchyIT.java	Adds an IT to ensure list requests with fields=relatedEntities tolerate a pseudo-type related entity and still return resolvable refs.