https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- If the issue is fixed (the glue entry has the right entryCSN recorded), the set up still exposes another issue when sessionlog is not configured/available:
In the above scenario, when things settle and B is allowed to replicate from A, cn=parent,cn=suffix is recreated in the cluster (sometimes except D not sure why yet). This is because A has to do a present phase and sends all entries, including cn=parent,cn=suffix (it hasn't seen the delete yet) while B has processed the delete in full, so it has no information to reject it anymore (except contextCSN, which we ignore in this case).
We could start judging entries in the present phase by their entryCSN as compared to our cookie, but this way we make it harder to fix existing database differences (if replication failed somehow in the past).