The attached patch updates the testsuite to reproduce the issue: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170404-ITS-6545-testcase.patch

The issue is that there is information lost when creating the log entry: - the ordering of values is not guaranteed by LDAP, even though this is rarely an issue with OpenLDAP with main backends (unless some overlay interferes) - there is no way to record where one modification ends and another begins

The obvious way to fix this is to record that a modification has ended. This is technically a change to the accesslog format but delta syncrepl will recover by falling back to plain syncrepl (which it already does in the reported case).

We could also record the order modifications as well (implementing the X-ORDERED trait on the attribute), but that would break most consumers of this format.