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.