Storing the update to the contextCSN to the root object makes sense, but propagating that update through the accesslog? Even if it were intended behavior, shouldn't the server receiving the update directly generate a similar access log entry, rather than just the server applying it from the accesslog.
But practically speaking, the contextCSN on a given server should presumably reflect the most recent entryCSN that particular server has applied, and this would seem to break that. To illustrate I added a third contextCSN to my lab servers, with a stale CSN on ldap01-a:  [zimbra@ldap01-a ~ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN  dn:  contextCSN: 20170302203943.550330Z#000000#001#000000  contextCSN: 20170302175436.282737Z#000000#002#000000  contextCSN: 20160302175436.282737Z#000000#003#000000   [zimbra@ldap01-b ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN  dn:  contextCSN: 20170302203943.550330Z#000000#001#000000  contextCSN: 20170302175436.282737Z#000000#002#000000  contextCSN: 20170302175436.282737Z#000000#003#000000 Wrote a new entry on ldap01-a (which is SID 001). The change propagated to ldap01-b, wrote an auditModify to the accesslog with its new contextCSNs:  dn: reqStart=20170302214742.843377Z,cn=accesslog  objectClass: auditModify  structuralObjectClass: auditModify  reqStart: 20170302214742.843377Z  reqEnd: 20170302214742.844297Z  reqType: modify  reqSession: 100  reqAuthzID: cn=config  reqDN:  reqResult: 0  reqMod: contextCSN:= 20170302214737.049475Z#000000#001#000000  reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000  reqMod: contextCSN:= 20170302175436.282737Z#000000#003#000000  reqEntryUUID: e1475404-93d7-1036-989f-315f78f5905f  entryUUID: 9bceae9e-93dd-1036-8a51-85a9c542cb5f  creatorsName: cn=config  createTimestamp: 20170302214737Z  entryCSN: 20170302214737.049475Z#000000#001#000000  modifiersName: cn=config  modifyTimestamp: 20170302214737Z Which was subsequently read by ldap01-a: Mar  2 16:47:42 ldap01-a slapd[9577]: syncprov_search_response: cookie=rid=100,sid=001,csn=20170302214737.049475Z#000000#001#000000 And now it has an updated contextCSN for 003 despite receiving no update for that SID: [zimbra@ldap01-a ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302214737.049475Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 I'm not sure if there is any guard against writing an older contextCSN than is currently stored, but this could theoretically rewind the stored contextCSN on A if there is any latency in replication from B. This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.
