[Bug]: LDAP not all primary group members might be fetched

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

In Group_LDAP::usersInGroup we fetch all groups, and slice only afterwards according to the limit and offset parameters. This applies to the normal members only. Members who have this group as primary are retrieved in a paged manner. I.e. only the initial request is being done as long as the cache is warm.

Steps to reproduce

It was not reproduced yet, but found while revisiting the code.

Expected behavior

All members should be retrieved properly.

The easy approach, and perhaps that should be done first, would be to fetch all primary users completely, so that slicing will work correctly afterwards.

The better solution would be to only retrieve the only necessary portion of members straight away. At the moment this is not done, to have a consistently correct results, e.g. no overlapping or missing groups due to memberships changes between requests (race condition). Since this method is used by front end code, the current implementation means potentially long waiting times with cold cache.

A very different approach would be to response (to web) with known members (oc_ldap_group_members table) which is potentially updated each hour. CLI requests would still need to be able to update members and cache so that background jobs are working. This mechanism could only work when cron/systemd jobs are utilized. This different strategy could be used in other places as well. Own background jobs may switch to private methods to not increase complexity further.

Installation method

No response

Operating system

No response

PHP engine version

No response

Web server

No response

Database engine version

No response

Is this bug present after an update or on a fresh install?

No response

Are you using the Nextcloud Server Encryption module?

No response

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

- user_ldap

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

@come-nc @CarlSchwan for your info and thoughts

Start with the Group_LDAP::usersInGroup entry point and trace how normal and primary group members are fetched, paged, and then sliced by limit and offset. Compare the behavior with the oc_ldap_group_members table and the frontend and CLI use cases; done means all primary members are returned correctly without missing or overlapping results.