fix(opensearch): honor sort=score in OS non-scroll read path (#36494)

[fabrizzio-dotCMS]

Proposed Changes

Fixes #36494.

During the ES→OpenSearch migration, content queries sorting by relevance (sort=score) silently lost their ordering once reads switched to OpenSearch (Phase 2+): they came back in default moddate desc order instead of _score order. HTTP 200, plausible-looking hit set, wrong order — the kind of regression count-based parity checks can't catch. Root cause: ContentFactoryIndexOperationsOS.addSorting's sortBy.startsWith("score") branch added only the secondary sort and never the primary _score sort.

Note (post-rebase): the core _score-sort fix has since landed on main via #36501/#36557 (fix(os-search): honor track_total_hits and _score sort on the OpenSearch read path), which added the same primary/secondary sort to this branch. After merging main, the net contribution of this PR is now:

1. unmappedType(Date) hardening on the secondary sort, and
2. the regression tests for sort=score (which main does not have).

What this PR still changes

Production — ContentFactoryIndexOperationsOS.addSorting: add unmappedType(Date) to the secondary field sort in the score branch, matching the scroll path (OSContentletScrollImpl). Without it, sort=score <field> fails on indices where the secondary field is not mapped, instead of degrading gracefully. Behavior for all other sort inputs is unchanged.

Tests

Added to OpenSearchUpgradeSuite (ContentFactoryIndexOperationsOSIntegrationTest) — new coverage not present on main:

• test_searchHits_sortByScore_shouldOrderByRelevanceNotModdate — indexes docs so relevance order is the exact reverse of moddate order; asserts scores come back descending and the most-relevant doc is first (guards against the original regression).
• test_searchHits_sortByScore_secondaryOverride_shouldApplySecondarySort — equal-score docs, sort=score moddate asc; asserts the secondary sort breaks the tie.

Acceptance Criteria

• addSorting adds the primary _score (desc) sort in the score branch, secondary sort after it (now on main via bug(index): product fixes & findings from phased (ES→OS) integration runs #36501/fix(os-search): honor track_total_hits and _score sort on the OpenSearch read path (#36501) #36557; preserved through the merge).
• Secondary sort uses unmappedType(Date) so sort=score <field> does not fail on indices missing that field.
• sort=score returns relevance ordering in Phase 2/3 (suite coverage).
• sort=score <field> <dir> secondary-sort override behaves correctly (suite coverage).
• Scroll path (OSContentletScrollImpl) unchanged (already correct).

🤖 Generated with Claude Code

This PR fixes: #36494

[claude]

Claude finished @fabrizzio-dotCMS's task in 58s —— View job

---

Code Review: fix(opensearch): honor sort=score in OS non-scroll read path

• Read production diff (ContentFactoryIndexOperationsOS.addSorting)
• Compared against scroll path (OSContentletScrollImpl.applySorting) and ES path
• Reviewed added integration tests
• Verified imports

Summary

The fix is correct and minimal. The score branch now adds the primary _score (desc) sort before the secondary field sort, and the secondary FieldSort gains unmappedType(FieldType.Date). This makes the non-scroll path (ContentFactoryIndexOperationsOS.java:342-346) an exact match of the already-correct scroll path (OSContentletScrollImpl.java:287-291). The FieldType import is already present (ContentFactoryIndexOperationsOS.java:30), so it compiles cleanly. Behavior for all non-score sort inputs is untouched.

The two added tests are well-designed regression guards:

• test_searchHits_sortByScore_shouldOrderByRelevanceNotModdate deliberately inverts relevance order against moddate order, so it fails pre-fix (returned C,B,A) and passes post-fix (A,B,C) — a real guard, not a tautology.
• test_searchHits_sortByScore_secondaryOverride_shouldApplySecondarySort isolates the tie-break by giving all docs identical _score, correctly exercising the sort=score <field> <dir> override path.

New Issues

No issues found.

Notes (non-blocking, pre-existing — not introduced by this PR)

• A caller override like sort=score title asc would feed a non-date field name into a secondary sort hard-coded with unmappedType(FieldType.Date), and (unlike addBuilderSort) it is used raw without the _dotraw suffix. This is a pre-existing design shared verbatim with the scroll path, so it's out of scope here — but if a non-date secondary override is ever a real use case, both paths would need the field-type inference logic. Not a regression from this change.

The PR does exactly what it claims, aligns the two OS read paths, and adds meaningful coverage. LGTM.

| Branch: issue-36494-os-sort-score

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request