Info received from hasNextPage is wrong in some resolvers

[MateoGuerreroE]

Describe the bug
When fetching data through a resolver we have that connects to a table with 4k+ records, It returns the data correctly, but for some reason returns hasNextPage: false when fetching more than (oddly specific) 373 records. Any number before that works normally, but If we try to fetch 373, 500, 1000 etc, It will state there are no more next pages. This happens in a single resolver of all we have exposed, but It is built exactly as other.

Have you read the Contributing Guidelines?

Yes

To Reproduce
Steps to reproduce the behavior:

1. Fetch data through resolver and include paging: { first: ... } with a number above 372.
2. Notice, It will return the hasNextPage: false even when the totalCount indicates the existence of more records.

Expected behavior
The hasNextPageattribute should show as true

Screenshots

Desktop (please complete the following information):

• Node Version: 21.7.1
• Nestjs-query Version: 6.1.0 (Tried with 6.1.1 and same thing happens)

Additional context
If I connect to a copy of the DB which has 1.8k records fetched on that same resolver, It works just perfect, so we tried to check If this has something to do with the number of records. Tried with some resolvers connected to tables that have +10k records and they work fine. Also, when trying to fetch next page using endCursor, It correctly returns next page, but still states hasNextPage as false, only says It's true on previous to last page.

[TriPSs]

Which ORM are you using?

Notice, It will return the hasNextPage: false even when the totalCount indicates the existence of more records.

totalCount is not used for this, what it does it fetches n + 1, then it checks if the n is bigger then what the user provided, if yes hasNextPage will become true; this way there is no need for a additional query.

[MateoGuerreroE]

TypeORM & Postgre - Checked the executed SQL and as you mention If I set 373 It goes for LIMIT 374 and executing that SQL manually correctly gives 374 records (On the same example provided)

[TriPSs]

Interesting, did you log the exact query TypeORM runs? (If you enable logging) And does that one return the correct results?

[MateoGuerreroE]

Yes, I got two on the console, one for results and one SELECT COUNT(*) which should be for the totalCount, I executed them (copy-paste) manually using dbEaver and return that extra record normally. Weird enough: I just tested again using same resolver (same code) but another DB which reaches 10.9K records and works fine. I can't see how this could be related to the database.

[TriPSs]

Interesting, using bigints maybe? I also can't think about anything that could cause this.

Think its also impossible to create a repo that reproduces this issue?

The output between the version that works and that does not work is also exactly the same? Maybe log this within the typeorm adapter to be sure.