fix: check for negative limit, offset and page search param

[martakam]

Since these are the values the users could enter incorrectly, no matter whether it was consciously or not, we should be able to handle these situations.

Closes #114

[hestro]

This is nice!

I don’t know how important this is, but while testing I found that /books?page=999999 shows “No books found for this search”, and /books?page=999999999 shows the “error loading the books” message.
Edit: after the changes in #116 , both URLs now show “No books found for this search”, so the error message is gone.

On /profile, a page beyond the last one redirects to page 1, which works nicely imo. It might be worth handling /books the same way?

Either way I’m approving

[johahor]

This is nice!

I don’t know how important this is, but while testing I found that /books?page=999999 shows “No books found for this search”, and /books?page=999999999 shows the “error loading the books” message. On /profile, a page beyond the last one redirects to page 1, which works nicely imo. It might be worth handling /books the same way?

Either way I’m approving

Good findings, and the two cases have different causes:

• ?page=999999999 gives an offset of almost 12 billion, which doesn't fit in GraphQL's 32-bit Int, so the API rejects the request. This is already fixed in fix: limit the maximum number of data rows fetched at once, other parameter checks #116.
• ?page=999999 is a valid request for a page that doesn't exist, so the result is just empty. Redirecting to page 1 like the profile page does sounds good, but I think it belongs in its own issue rather than this PR.

Merging this one now, then #116.

[hestro]

This is nice!
I don’t know how important this is, but while testing I found that /books?page=999999 shows “No books found for this search”, and /books?page=999999999 shows the “error loading the books” message. On /profile, a page beyond the last one redirects to page 1, which works nicely imo. It might be worth handling /books the same way?
Either way I’m approving

Good findings, and the two cases have different causes:

• ?page=999999999 gives an offset of almost 12 billion, which doesn't fit in GraphQL's 32-bit Int, so the API rejects the request. This is already fixed in fix: limit the maximum number of data rows fetched at once, other parameter checks #116.
• ?page=999999 is a valid request for a page that doesn't exist, so the result is just empty. Redirecting to page 1 like the profile page does sounds good, but I think it belongs in its own issue rather than this PR.

Merging this one now, then #116.

Thanks! I also noticed that #116 fixes that. Agree that the redirect could be its own issue.