GraphQL pagination appears to be broken with includeSubGroups
Summary
When attempting to iterate through all projects on our self-hosted gitlab instance, using this query:
query GroupRepositories {
group(fullPath: "our-root-group-name") {
projects(includeSubgroups: true, after: "a-cursor", first: 30) {
nodes {
id
},
pageInfo {
hasNextPage,
endCursor,
hasPreviousPage,
startCursor
}
}
}
}
After paginating once, and passing the correct after
cursor, we end up with a result like so:
{
"data": {
"namespace": {
"projects": {
"nodes": [
{
"id": "gid://gitlab/Project/56"
},
... snip ...
{
"id": "gid://gitlab/Project/63"
}
],
"pageInfo": {
"hasNextPage": false,
"endCursor": "NjM",
"hasPreviousPage": false,
"startCursor": "NTY"
}
}
}
}
}
As you can see the pageInfo
object has false
for both hasNextPage
and hasPreviousPage
. That's impossible, we have over 600 projects on Gitlab under the root group we use and this is the second page of the results.
I've been playing with this and cannot see a pattern here: it's possible to continue to paginate using the endCursor
but you gradually get less and less results.
I have tried to reproduce this on Gitlab.com with the gitlab-org
group but to no avail. Possibly due to the lack of heavily nested groups.
Steps to reproduce
We have a deeply nested structure of groups:
our-org-name/
sub-group-name/
business-unit1/
business-unit2/
python/
libraries/
devops/
containers/
language/
I think this kind of structure brings out a limitation or bug in the includeSubGroups
implementation. If I do a query on our-org-name/sub-group-name/
, which has about 40 projects in, I get a complete set of results with working pagination.
What is the current bug behavior?
After paginating a large, nested tree of projects you can end up with a logically impossible cursor that says there is no previous or next page.
What is the expected correct behavior?
Pagination works as documented
Results of GitLab environment info
I'm sorry, it's not possible for me to gather this right now. If you really require it I can see if I can prod the right people. We are running Gitlab 12.3.3-ee
, but this issue was present on 12.2.x
as well.
~bug