On Thu, Jun 16, 2022 at 13:50:52 +0200, Ondřej Kuzník wrote:
Hi Geert, you mean the CSN recorded (a.k.a. "entryCSN:", not "reqMod: entryCSN:=") for these failed ops is still the original one rather than a new local SID? That would mean the ITS#9641 fix is not working and if that's the case, can you provide a test set up that reproduces this?
Yes, we see the replica's get an updated contextCSN with SID from the provider, only the provider itself makes no change to its contextCSN and stays with the old one, ie. the consumers appear to be ahead of this provider. So for me, the behaviour of 2.6 and master is still the same as 2.4/2.5.
Regarding your fix, you mean the replica (*each* replica?) will increase the contextCSN for its own SID for this operation? That seems strange to me, for a failed/refused update on another provider, I would expect no change at all on the replica's (and esp. the contextCSN associated with their SID's to never change as long as they receive no updates directly).
The reproduction scenario is simply: MPR setup with "logsuccess FALSE", then ldapdelete an object which does not exist. => contextCSN on the replica's get updated (there is not even an entryCSN involved here).
Geert