https://typesense.org logo
Join Slack
Powered by
Hello team! We have some problems with the case w...
# community-help
m
Hello team! We have some problems with the case when 
perPage
is changed for the next query. Issue description: We have a server limit for a given collection equal to 50. In the app, we use pagination = 20. For this case we cannot send 3x queries with perPage=3 because the server response is : `Request failed with the status code: 422. Server said: Only upto 50 hits can be fetched. Ensure that 
page
and 
per_page
parameters are within this range.` (I know because I got it🫠) So to respect the limit, we recalculate 
perPage
for last query. So for the described case, we send 3 queries with perPage: 20, 20, 10. The problem is that for the last query, the results are duplication for the previous one. To give you a better picture of ​​the problem, here is the output for simplified cases - please notice that the problem with duplication occurs only for case when we change perPage for next querry:
👀 1
Let me know if the data provided is sufficient. I can provide full output for the described case with a server limit of 50.
👀 1
@Shaun Byrnes
k
Would you be able to DM me the exact curl commands that will show case the issue?
s
@Matt can you provide this
@Kishore Nallan in general, what should be the handling for this sort of thing?
Surely, if the server side scoped keys returned have a limit, that should not break the paging on the client end? As in, I would expect the behaviour should be if the user requests more than the limit it is simply capped to that?
that way if they want 100 rows per page on client and the server limit is 50, then they would just get n-limit (50 rows) returned
Or if 20 per page then 20+20
on "page 3" 20 > limit so return difference 
(pages * rowPerPage) - limit
something of the sort
Or are we missing something from the API docs ?
I would prefer to keep the rows per page at 20 as it is - I could change the server side limit to 60 meaning 20+20+20 would be ok, or I could change rows per page to 10, meaning 10+10+10+10+10 would be ok, or simply remove the server side limit entirely - but I would rather know the correct intended way to provide a server side limit with proper pagination (assuming its not just a TS bug)
k
Yeah I think the correct fix here is to not throw an error but just limit returned records. However the actual issue of duplication should not happen.
s
yeah
so you think its a TS bug then ?
k
Does the same repetition issue happen when you set limit to 60, do per page of 20 and access page 3?
The limit exceed error is just an inconvenience that we can fix. But I think the repetition could be an actual issue. Which is why I need the full query.
s
Gotcha
Iirc, if we change to a page number like 5 or 10 which will returned n pages without a remainder (from the limit of 50), we don’t see the error or duplicates
I will ask Mat to confirm
k
So the issue here is that on page 3, you can't go back and set 
per_page=10
because we calculate the offset by multiplying page and per_page. So, in effect, older data will get returned.
I will fix the issue of an error being thrown when requested records exceed limit set. That will solve the issue.
👍 1
s
Yep cool makes sense
That’s what I thought- I told him changing the per page after results are back would likely cause issues - but I think was his attempt to handle underlying bug
If you can fix those 2 things as described above then we should be able to keep 50 limit with 20 records per page and have page 3 only give difference of 10 back
k
Which two things? What I am going to fix is not returning an error, but just make pagination return only upto limit_hits.
👍 1
s
Sorry correct
I meant just that
I just read it as 2 things in my head
Given a) not return error and b) limit rows
Haha
k
😄
s
Hopefully you can do that hot fix soon as it’s broken in our current builds atm
k
Yes, I will share a build by EOD.
❤️ 2
s
Legend
hey @Kishore Nallan did you end up making that build? I didnt see any updates available for v27 yet
k
I've just published 
28.0.rc1
. Try it on staging first.
s
Ok
Will it show up as a choice on TS cloud ?
I just checked 5 mins ago and wasn’t there
as yes its there
ok applying update now
this as the limit changes in it correct ?
k
Yes
s
ok cool
so the new expected behavior is that the limit error wont be returned it will just cap the results to limit correct ?
for example if we put a limit of 30 and then request 50 rows per page we jsut get 30 back, no error
or if we have 10 rows per page and a limit of 25, we get 10,10,5 and no error correct ?
k
Yes, we will just truncate to the limit instead of returning error.
s
yep
nice
will check it and let you know
👍 1
Open in Slack
PreviousNext
Powered by