feat(contextCenter): support sortBy/sortOrder on page hierarchy search

[sonika-shah]

What

Adds sortBy / sortOrder query params to GET /v1/contextCenter/pages/search/hierarchy so the Context Center left-tree can control ordering — e.g. a newly created article or quick link surfaces at the top instead of the bottom.

Fixes open-metadata/openmetadata-collate#4781 (item 1 — article hierarchy sorting).

How

Threads a SearchSortFilter from the resource through KnowledgePageRepository → the SearchClient interface → the ES/OS client implementations:

• KnowledgePageResource — listHierarchyWithSearch gains sortBy (name / createdAt / updatedAt) and sortOrder (asc / desc). Reuses the existing resolveSortField / resolveSortOrder validators, so invalid values return 400. Default is updatedAt desc (newest first).
• ElasticSearchClient / OpenSearchClient — a shared buildPageHierarchySortOptions applies the requested primary sort, then always appends fullyQualifiedName (keyword, unique per page) as a stable tiebreaker so from/size pagination cannot miss or duplicate hits when the primary sort field (e.g. updatedAt) is non-unique.
• SearchClient / KnowledgePageRepository — signature threading only.

The Collate ElasticSearchClientExt / OpenSearchClientExt override these same methods; the matching Collate change is in openmetadata-collate (linked below) and depends on this PR + a submodule bump.

Tests

KnowledgePageHierarchyIT gains three cases:

• testSearchHierarchyRejectsInvalidSortBy → 400
• testSearchHierarchyRejectsInvalidSortOrder → 400
• testSearchHierarchySortsByName → asc aaa < mmm < zzz, desc reversed (Awaitility-gated on the search index)

Verified locally: mvn spotless:check, compile (openmetadata-service), and test-compile (openmetadata-integration-tests) all pass.

Greptile Summary

The PR adds configurable, stable ordering to Context Center hierarchy search.

• Accepts and validates hierarchy sort field and direction parameters.
• Threads the sort filter through the resource, repository, and search-client layers.
• Applies deterministic Elasticsearch and OpenSearch ordering with an FQN tiebreaker.
• Adds integration coverage for validation and name ordering.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
openmetadata-service/src/main/java/org/openmetadata/service/resources/knowledge/KnowledgePageResource.java	Adds validated hierarchy sort parameters and forwards the resulting filter to both hierarchy query paths.
openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/KnowledgePageRepository.java	Threads the hierarchy sort filter from the resource into the configured search client.
openmetadata-service/src/main/java/org/openmetadata/service/search/SearchClient.java	Extends the hierarchy-search interface methods with a sort-filter parameter.
openmetadata-service/src/main/java/org/openmetadata/service/search/elasticsearch/ElasticSearchClient.java	Applies the requested primary hierarchy sort and a deterministic FQN tiebreaker to Elasticsearch requests.
openmetadata-service/src/main/java/org/openmetadata/service/search/opensearch/OpenSearchClient.java	Applies equivalent stable hierarchy ordering to OpenSearch requests.
openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/KnowledgePageHierarchyIT.java	Covers invalid sorting parameters and observable ascending and descending name ordering.

Sequence Diagram

sequenceDiagram
  participant UI as Context Center UI
  participant Resource as KnowledgePageResource
  participant Repo as KnowledgePageRepository
  participant Search as SearchClient
  participant Index as Elasticsearch/OpenSearch
  UI->>Resource: "GET /search/hierarchy?sortBy&sortOrder"
  Resource->>Resource: Validate and build SearchSortFilter
  Resource->>Repo: getHierarchyWithSearch(..., sortFilter)
  Repo->>Search: listPageHierarchy(..., sortFilter)
  Search->>Index: Search with primary sort + FQN tiebreaker
  Index-->>Search: Ordered hierarchy hits
  Search-->>UI: "ResultList<PageHierarchy>"

Loading

_{Reviews (3): Last reviewed commit: "refactor(contextCenter): honest sort con..." | Re-trigger Greptile}

Context used:

• Knowledge Base — OpenMetadata Service Core: Entities, Resources, Repositories
• Knowledge Base — Search Indexing and Event/Notification Sync

[github-actions]

❌ PR checklist incomplete

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

• Linked issue open-metadata/openmetadata-collate#4781 does not exist or is not accessible.

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.

[sonika-shah]

Superseded by #31625, which targets main (correct flow: land on main first, then cherry-pick to 2.0). Same changes. Closing this 2.0-based PR.

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Adds validated sortBy and sortOrder parameters to context-page hierarchy search, threading the sort filter through the repository and search backends with a stable tiebreaker. Addressed the createdAt sorting mapping issue.

✅ 1 resolved

✅ Bug: sortBy=createdAt silently sorts by updatedAt

📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/knowledge/KnowledgePageResource.java:307-314 📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/knowledge/KnowledgePageResource.java:402-409
The new hierarchy endpoint advertises createdAt as a supported sortBy value (allowableValues), but resolveSortField maps both createdAt and updatedAt to the updatedAt field, and the page search index has no createdAt mapping at all. A client requesting sortBy=createdAt therefore silently gets pages ordered by last-modified time, which differs from creation order for any page that has been edited. Either add a createdAt field to knowledge_page_search_index.json and map createdAt -> "createdAt", or remove createdAt from the documented allowableValues so the contract is honest.

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 👍 / 👎 | Powered by Gitar — free for open source}