Consider sort defined by sortBy(…) in fluent Specification slice and unpaged queries.

[kmdy7991]

FetchableFluentQueryBySpecification uses pageable.getSort() in readSlice(…) and in the unpaged branches of slice(…), page(…), and page(…, countSpec), so a Pageable without a sort drops the sort configured through sortBy(…). The Querydsl counterpart, FetchableFluentQueryByPredicate, uses pageable.getSortOr(this.sort) in the analogous page/slice paths and keeps the fluent sort as the fallback.

This change applies the same getSortOr(…) fallback to the Specification variant and adds regression tests for the unsorted-PageRequest slice path and the unpaged terminals. The existing GH-3762 tests only use PageRequests that carry a sort (the override case), which is why the missing fallback went unnoticed.

Tests:

• ./mvnw.cmd -pl spring-data-jpa -Dtest=UserRepositoryTests test

---

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

Closes #4297

[mp911de]

This is intentional behavior:

spring-data-jpa/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/JpaSpecificationExecutor.java

Lines 275 to 281 in 4a606f6

	* {@literal null}. The given {@link Pageable} will override any previously specified {@link Sort sort} if
	* the {@link Sort} object is not {@link Sort#isUnsorted()}. Any potentially specified {@link #limit(int)}
	* will be overridden by {@link Pageable#getPageSize()}.
	* @param countSpec specification used to count results.
	* @return
	*/
	default Page<T> page(Pageable pageable, PredicateSpecification<?> countSpec) {

and this is part of the contract:

https://github.com/spring-projects/spring-data-commons/blob/c64558c964c86903a3b9143b8961323d932058fe/src/main/java/org/springframework/data/repository/query/FluentQuery.java#L231-L235

With that in mind, we need to revise FetchableFluentQueryByPredicate to align with the contract. Pagination may introduce two potentially conflicting sort definitions. Since Pageable already encapsulates a Sort, it should override any previously configured sort.

[kmdy7991]

@mp911de

Thank you for the clarification — that makes sense, and I'm happy to rework this in that direction.

Two things I noticed while looking into what the alignment would touch, just to scope it correctly:

1. The JpaSpecificationExecutor Javadoc for page(Pageable, PredicateSpecification) currently states the conditional rule ("…will override any previously specified sort if the Sort object is not Sort#isUnsorted()"), so it would need updating to the unconditional wording along with the code.
2. readPage(…) in FetchableFluentQueryBySpecification also uses pageable.getSortOr(this.sort) today, and a few existing tests assert the fallback behavior (findByFluentSpecificationPageCustomCountSpec / Support custom countSpec in SimpleJpaRepository.findAll #3727 with an unsorted PageRequest, and findByFluentPredicateSlice / Add support for findBy(…) using Querydsl Predicate that returns a Slice #3764 on the Querydsl side) — those would need adjusting as well.

Would you like me to rework this PR to do that — align FetchableFluentQueryByPredicate (and readPage(…)) on pageable.getSort(), update the Javadoc, and adjust the affected tests — or would you prefer to handle it on your side? Either way works for me.