(ITS#8559) Syncrepl stuck after duplicated attribute modification on master

[matheus_morais@sicredi.com.br]

Full_Name: Matheus Morais
Version: 2.4.42
OS: Red Hat 6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (201.77.94.55)


In an environment with syncrepl properly configured, if one modification with
duplicated attributes values is applied on the "master" node, the "slave" stuck
the replication until the entry is removed from cn=accesslog.

Here is one LDIF example:

dn: ou=marili_advogados,ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br
changetype: modify
-
replace: SicrediEntidadePai
SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br
-
replace: SicrediEntidadePai
SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br

This change is processed by master and appears like that on the cn=accesslog:

dn: reqStart=20170103135721.000411Z,%3=accesslog
objectClass: auditModify
reqStart: 20170103135721.000411Z
reqEnd: 20170103135721.000413Z
reqType: modify
reqSession: 1184351
reqAuthzID: cn=manager,dc=br
reqControls: {0}{2.16.840.1.113730.3.4.2}
reqDN: ou=marili_advogados,ou=terceiros,%n=sistema,cn=entities,dc=sicredi,dc=c
 om,dc=br
reqResult: 0
reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc
 =com,dc=br
reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc
 =com,dc=br
reqMod: entryCSN:= 20170103135721.874447Z#000000#000#000000
reqMod: modifiersName:= cn=manager,dc=br
reqMod: modifyTimestamp:= 20170103135721Z
reqEntryUUID: 61dfd779-5799-4988-927b-914e75d6ae90

When the slaves try to apply that change, it results in a constraint violation.
We can see that kind of message on the slaves logs:

2017-01-03T19:14:21.043501-02:00 ds1openldap5p slapd[2245]:
syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values
provided)
2017-01-03T19:14:21.043599-02:00 ds1openldap5p slapd[2245]: do_syncrepl% r
rid=000 rc 19 retrying
2017-01-03T19:15:21.039822-02:00 ds1openldap5p slapd[2245]:
syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values
provided)
2017-01-03T19:15:21.039863-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=000
rc 19 retrying

I think we have two options here:

1 - This kind of LDIF should result in a constraint violation on the master node
and the modification is not recorded on cn=accesslog.
2 - The accesslog overlay should remove the duplicated values from attributes.

The first option seems more rational IMHO.