The following diagnosis was provided by a customer who ran into this issue:
It looks as if the code (we are looking at Stash 2.7.1) that queries for nested groups is not handling the case of having more than 100 direct parents.
private List<Group> findNestedGroupMembershipsOfUser(final long directoryId, final String username, GroupType groupType, final int maxResults)
throws OperationFailedException, DirectoryNotFoundException
{
List<Group> directGroupMemberships = searchDirectGroupRelationships(directoryId, QueryBuilder.queryFor(Group.class, EntityDescriptor.group(groupType)).parentsOf(EntityDescriptor.user()).withName(username).returningAtMost(maxResults));
return findNestedGroupMembershipsIncludingGroups(directoryId, directGroupMemberships, groupType, maxResults, true);
}
This findNestedGroupMembershipsOfUser method is called by Filter.scan() in a loop. Filter is trying to send the underlying query a start index and a max number of items to grab, but by the time it gets to findNestedGroupMembershipsOfUser, it only has a maxResults.
If a user has, say, a few hundred direct parent groups, and 600 total nested groups, then findNestedGroupMembershipsOfUser will get called 6 times, with maxResults set to [100, 200, 300, 400, 500, 600]. The output of findNestedGroupMembershipsOfUser will contain bad results, including duplicate entries between calls with different maxResults, since there is no start offset, and since it is also limiting the directGroupMemberships by the same maxresult.
In order to work around this problem for now, we've had to change Filter.FETCH_SIZE from 100 to 4000. This guarantees, in our case, that all crowd user/group queries return in a single page, and thus avoid this bug.
The following diagnosis was provided by a customer who ran into this issue:
It looks as if the code (we are looking at Stash 2.7.1) that queries for nested groups is not handling the case of having more than 100 direct parents.
This findNestedGroupMembershipsOfUser method is called by Filter.scan() in a loop. Filter is trying to send the underlying query a start index and a max number of items to grab, but by the time it gets to findNestedGroupMembershipsOfUser, it only has a maxResults.
If a user has, say, a few hundred direct parent groups, and 600 total nested groups, then findNestedGroupMembershipsOfUser will get called 6 times, with maxResults set to [100, 200, 300, 400, 500, 600]. The output of findNestedGroupMembershipsOfUser will contain bad results, including duplicate entries between calls with different maxResults, since there is no start offset, and since it is also limiting the directGroupMemberships by the same maxresult.
In order to work around this problem for now, we've had to change Filter.FETCH_SIZE from 100 to 4000. This guarantees, in our case, that all crowd user/group queries return in a single page, and thus avoid this bug.