What you are wondering about is attribute level conflicts
I don't *think* I am. The one problem I'm trying to understand right now is based
on a simple password change. That password change generates many attribute changes on a
single entry: password history, various krb attributes, etc. What I saw from audit logs is
that those various attribute changes on the one entry got split into two ldap
modifications. The audit log shows that all of my servers got one of the modifications,
but a few failed to get the other.
The thing I've been pursuing here is if those both had the same CSN, since they were
created at the same time on the same replica, then it's possible that one of my
replicas got an update that contained only one of the modifications, recorded it as the
most recent CSN from that replica, and then a second attempt to push the second one
resulted in the check seeing that it already had the most recent update and failing to
make that other change.
I recognize that that's a lot of weirdness. Everything I read claims that CSNs
aren't inextricably tied to timestamp, in order to make sure that they're unique,
so that would suppose a bug in that system. And then the idea that one of those updates
would be carried separately from the other seems like an odd situation, at best. The more
I understand about the replication system, the less likely this hypothesis seems. But
I'm having a hard time coming up with another.