arun s wrote:

Hi, Yes, I am able to reproduce the issue with 2.4.32

Making sense of the logs for the exact reproduction is hard since it needs a lot of operations in a short time. But this will probably help:

1. At the start of the test, the group temp_group existed.

2. I created a user temp_user and added temp_user to temp_group.

3. During replication, the group was replicated first and I got an error 32

(NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object (This does not exist in the readslave yet).

4. The temp_user object was replicated next, and as you see, querying it does

show a memberOf attribute, proving that this field was replicated. (Note that I have run OpenLDAP with debug as -1 and verified that the replicated data has the memberOf field in it. I can provide this too if needed.)

I see. The current code drops the memberOf attribute if it was not explicitly requested in the search. However, by default the consumer requests "+" which means "all operational attributes" and so slapd considers memberOf to have been requested. We need to reconsider this aspect of the design.

5. The more serious problem occurs when the sequence is reversed and the group

has been deleted as a last operation - The user is replicated first, but since the group is deleted, it is never replicated and a stale memberOf entry stays with the user.