-
-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support more than one digit of pagination metadata in listUsers()
#793
base: master
Are you sure you want to change the base?
Conversation
links.forEach((link: string) => { | ||
const page = parseInt(link.split(';')[0].split('=')[1].substring(0, 1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The .substring(0, 1)
here is the cause of the truncation
listUsers()
listUsers()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this! We've got an outstanding item to fix the pagination in GoTrue but it's going to be a while.
@@ -194,10 +194,14 @@ export default class GoTrueAdminApi { | |||
const total = response.headers.get('x-total-count') ?? 0 | |||
const links = response.headers.get('link')?.split(',') ?? [] | |||
if (links.length > 0) { | |||
const regex = /page=(\d+)(?=&)[^>]*>; rel="(\w+)"/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually would you mind pulling this regex up to the top scope, so that a new object is not being created every time the function is called?
Also, is it possible to not use a regex here at all? Maybe use URLSearchParams
instead?
What kind of change does this PR introduce?
Fixes an issue where the pagination metadata returned from
listUsers()
was inaccurate for page values>= 10
.What is the current behavior?
The current behaviour assumes the
page
value contained in the link string (each element of which looks a bit like this:</admin/users?page=7&per_page=10>; rel="last"
) is always a single digit, leading to truncated values fornextPage
andlastPage
being returned if either are 10 or more. For example, ifnextPage
is10
, the current behaviour truncates this to1
. If the client is relying on the value ofnextPage
, this could cause it to paginate up to page 9 correctly but then reset to page 1 rather than move on to page 10.What is the new behavior?
The new behaviour correctly parses multi-digit values for
nextPage
andlastPage
.Additional context
I couldn't get the test suite running but didn't see any tests relating to this so I don't think any tests will break. I patched the proposed changes into the project I have which was being tripped up by this behaviour and they appear to work as expected. Feel free to refactor - wasn't sure if changing the various
split()
calls to a regex was a no-no.Thanks!