Full_Name: Emily Backes Version: 2.4.26 OS: any URL: Submission from: (NULL) (75.244.124.114)

If a client connects and writes, e.g. ADDs entries, then disconnects before seeing the result, the writes are stored in the database but do not increment contextCSN.

This can be seen without replicas being involved, but obviously still needs syncprov.

$ ldapadd -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -f people.ldif adding new entry "cn=1,ou=people,dc=example,dc=com"

adding new entry "cn=2,ou=people,dc=example,dc=com" ... adding new entry "cn=22,ou=people,dc=example,dc=com" ^C

$ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL '(cn=22)' entryCSN dn: cn=22,ou=people,dc=example,dc=com entryCSN: 20111011235653.469937Z#000000#001#000000

$ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL -s base contextCSN dn: dc=example,dc=com contextCSN: 20111011235653.380889Z#000000#001#000000

stats+sync log:

conn=1000 op=21 ADD dn="cn=21,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.380889Z#000000#001#000000 conn=1000 op=21 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x10178e0a0 20111011235653.380889Z#000000#001#000000 conn=1000 op=22 ADD dn="cn=22,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.469937Z#000000#001#000000 slap_graduate_commit_csn: removing 0x10178e520 20111011235653.469937Z#000000#001#000000 conn=1000 fd=10 closed (connection lost)

The change isn't sent out to connected refreshAndPersist replicas either, and forcing them to reconnect doesn't help, as their contextCSNs still match across the board. This can cause persistent desynchronization of servers.