Partial migration to Infinite Query breaks pagination

[SpasiboKojima]

I followed the "Migration from Convex" guide and setup CRPC, updated my one of my query definitions on the server and client setup. The query still uses plain Convex calls with pagination. Schema is plain Convex too (seems like I can't easily migrate it due to using typedV from convex-helpers/validators).
The problem is that when the query can return 6 rows, and I set the limit to 3, it does 3 subsequent fetches until exhaustion and returns 3, 5, and finally 6 rows. hasNextPage also always false during this. My agent says that it's due to splitCursor in Convex's paginate return, but again I don't think I can easily partially migrate to ORM yet.
Can I do something here?

[zbeyens]

Fixed in PR #305: native Convex pagination no longer treats every splitCursor as a request to fetch another page. You can keep the native schema and paginator; with six rows and limit three, the first render stays at three with hasNextPage: true, and fetchNextPage() loads the remaining three then reports false.

[SpasiboKojima]

Sorry, still a little broken. limit: 2 returns 0 results, limit: 3 returns 1, limit: 4 to 6 return 2. pageStatus is always null for me. Anything else to be done here?

[zbeyens]

Thanks for the follow-up. I retested current main with a six-row native Convex query and pageStatus: null. Native Convex and the cRPC React adapter both return 2, 3, 4, 5, and 6 items for limits 2 through 6, so I cannot reproduce the 0, 1, 2, 2, 2 matrix from the clean path. pageStatus: null is a valid normal result. Could you share the server .paginated() definition and handler (including the call to paginate and any filtering or mapping afterward), the client infiniteQueryOptions/useInfiniteQuery call, and your kitcn and convex versions? A minimal repo would be ideal. With that exact case I can trace the remaining interaction instead of guessing.

[SpasiboKojima]

My bad, sorry, thanks for taking your time on checking that. Poor rewriting of a query which ended up having filtering after pagination.
Now I'm hitting the first issue again, this time when I have 5 rows and limit: 2 it works as expected, but with limit: 3 it does 2 subsequent queries. Is it intentional? I can kinda see that from the shouldSplitPaginationPage condition.

Not sure if it's my query but it looks roughly like this:

const eventsQuery = stream(ctx.db, schema)
	.query('events')
	.withIndex('by_isEnded', (q) => q.eq('isEnded', undefined));

const events = await eventsQuery
	.filterWith(async (event) => {
		if (event.isDeleted) return false;
		return true;
	})
	.paginate({
		numItems: input.limit ?? 20,
		cursor: input.cursor ?? null,
	});

return events;

[zbeyens]

Your query shape is correct: stream.filterWith runs before pagination. The extra requests are intentional once the paginator returns SplitRecommended, but this small filtered query should not recommend a split on current convex-helpers. I reproduced your pattern on convex-helpers 0.1.116 and 0.1.117: limit 2 scans only the first two matching rows, while limit 3 scans across filtered rows, emits SplitRecommended, and can cascade into extra split subscriptions. This was fixed upstream in convex-helpers 0.1.118 by making split recommendations less aggressive (get-convex/convex-helpers#962). Please upgrade to convex-helpers >= 0.1.118, preferably latest. The same five-row case returns 2 and 3 rows without split metadata on 0.1.118. If you are already on 0.1.118+, send the exact version plus the first result's page length, pageStatus, splitCursor, and isDone and I will trace the remaining difference.

[SpasiboKojima]

Oh wow, thank you very much! True I was on "convex-helpers": "^0.1.108", bumping to 0.1.120 and all runs well now.