https://bugs.openldap.org/show_bug.cgi?id=9282
Ondřej Kuzník <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #6 from Ondřej Kuzník <[email protected]> --- Thanks for the reproducer script. This is due to https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/syncrepl.c#L1638 causing A to skip the present cull. Based on the git history, this was introduced to deal with ITS#5470 but that seems wrong, if the number of SIDs in the cookie differs from what we requested then either: - a SID disappeared from the set we received, which sounds like what ITS#5470 is about? But slapd doesn't really allow this at the moment as it will say consumer is newer than provider) so that shouldn't happen - a SID is added to the set by the provider, like here. This could be due to a delete (like here) and that delete has to be replicated - that is the point of running syncrepl_del_nonpresent The above would not explain why server B then receives the deleted entry back rather than this being a silent desync. It turns out that check_syncprov() doesn't add SID 2 into the cookie[0] so it forgets its own modification when establishing the syncrepl session to A. Howard, can you review if any of the claims above seem wrong? [0]. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/syncrepl.c#L1638 - the loops should probably be inverted, with the outer loop operating on si_cookieState instead? -- You are receiving this mail because: You are on the CC list for the issue.
