https://bugs.openldap.org/show_bug.cgi?id=9282
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1
--- Comment #6 from Ondřej Kuzník ondra@mistotebe.net --- Thanks for the reproducer script.
This is due to https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/syncr... 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/syncr... - the loops should probably be inverted, with the outer loop operating on si_cookieState instead?