In the interests of full disclosure, I just did a slapcat / slapadd and the problem has gone away.

I'm not sure is the problem was created because of starting a 2.4.19 slapd, over the top of a database loaded by 2.4.16, or due to the obscure bug, occasionally mentioned, where syncrepl can gets itself into a odd state and wont converge.

The syncrepl state information on the producer would have been created with the slapadd -w option under 2.4.16, but executed under 2.4.19. I thought originally because the berkeleydb version (4.8) had not changed, this would be ok.

Out of interest, has the syncrepl UUID / CSN format changed much between 2.4.16 stable and 2.4.19 stable ?

Cheers
Brett