It's not clear to me where the issue is. What is the "right" sequence the add of the new superior and the mordrdn should be transmitted? Should the provider operate differently, or should the consumer check all syncrepl messages and try to rebuild the final state, instead of giving up when the internal lookup for the newsuperior fails? Probably, a workaround could be to perform the modrdn by crating the new superior as a glue object, which eventually will be replaced by the actual add.

I've quickly hacked things this way, and it seems to work fine.

ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.1.patch

Please let me know if this approach is sound enough, I might have overlooked some implications.

p.