KeysetAwarePage type is lost for JPA Query Methods

[mj-p]

KeysetAwarePage type is lost for JPA Query Methods

Description

For JPA Query Methods, Spring Data AbstractJpaQuery applies a ResultProcessor for slice/page-like return types, using:

(T) ((Slice<?>) source).map(converter::convert)

If source is KeysetAwarePageImpl, mapping currently goes through inherited PageImpl#map(...), which returns a plain PageImpl instance.

This loses keyset-aware type information (PageImpl instead of KeysetAwarePageImpl).

Observed behavior

Later, proxy/interceptor code paths expecting KeysetAwarePage fail with:

java.lang.ClassCastException: class org.springframework.data.domain.PageImpl cannot be cast to class com.blazebit.persistence.spring.data.repository.KeysetAwarePage

Expected behavior

Mapped results should preserve keyset-aware page type/metadata so downstream processing that expects KeysetAwarePage remains valid.

Root cause

KeysetAwarePageImpl inherits PageImpl#map(...), which re-materializes mapped content as PageImpl, dropping the concrete keyset-aware type.

Proposed fix

Override map(...) in KeysetAwarePageImpl to return KeysetAwarePageImpl while preserving:

• keyset page metadata
• pageable/keyset pageable semantics
• total elements

[mj-p]

Two additional points after further investigation:

1. Slice paths likely need equivalent handling as Page paths.

2. If KeysetAwarePageImpl#map(...) always returns KeysetAwarePageImpl, this may change observable behavior for users of regular JPA query methods returning Page with plain Pageable (i.e. not explicitly keyset-focused).
   In those mapping paths, results would preserve keyset-aware runtime types instead of degrading to PageImpl.

I’m concerned this could affect response serialization shape for some users.

[mj-p]

Two more things:

1. Slice keyset metadata can be inconsistent for navigation
   KeysetAwareSliceImpl receives a KeysetPage originating from the n + 1 slice fetch strategy (where maxResults effectively reflects pageSize + 1).
   That KeysetPage is then used for nextPageable() / previousPageable() calculations, which can produce incorrect navigation metadata.

2. map(...)/ResultProcessor behavior depends on projection conditions
   The problematic ResultProcessor mapping path is only taken when projection is actually applied (i.e. not when source already matches target type / no projection).
   In my application this path was hit because entity and entity-view types did not share the same common supertype arrangement used in tests (Indentifiable<T>), so map(...) was involved and the type loss surfaced there.

So effectively there is a workaround for my initial issue (i.e. using a common supertype for entities and views like Identifiable<T>) but a real bug seems to exist when using KeysetAwareSliceImpl which result from a query with a given KeysetPage via a KeysetPageable.