https://bugs.openldap.org/show_bug.cgi?id=9823
--- Comment #6 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #5)
On Mon, Apr 18, 2022 at 06:49:36PM +0000, openldap-its@openldap.org wrote:
--- Comment #4 from Shawn McKinney smckinney@symas.com --- The question, why doesn't it fallback into plain sync repl? Or, given some indication to the consumer (error) that it can't be brought back in sync, i.e. dsync has occurred.
Syncprov just lets the consumer replicate the current contents of the database (minus any deletions because syncprov-nopresent is set). It has no idea that deletes happened (there is no record of them) and how it all fits into the semantics of delta-syncrepl.
Deletes are irrelevant when polling the log. The log is a queue, appends at the tail and deletes from the head. The only check that's required is to see if the consumer's cookieCSNs are still present in the log. If not, then records that cover the cookie are gone, and a refresh from the mainDB is needed. That's why we use the nopresent config on the logDB, because a normal present phase is a bunch of work for no extra benefit.