I think this is fine and can be ignored. That replica ID should be cleaned up on the next update that the agreement processes. I will investigate to make sure

The agreement RUV does get cleaned up after some time(or a restart). It does not seem to cause any problems while it is present. The consumer RUV(the ruv in the agreement) is only used for changelog purging, but cleanallruv already does the purge at the end of the task.

Can this ticket be closed? Was there anything else I should look at?

it will be removed by an update if everything works fine, but what about the cases
- where a replica cannot be reached, temporararily or forever. In force mode we do not wait for the replica to come online and clean the ruv in the database and changelog, but in the agreeement it will be kept until the replica can be reached again
- where the server crashes before the update, will it be recreated fromthe dse.ldif having the old RID in the consumer ruv.

if it is not too hard, I still think it would be nice to clean the consumer ruv

attachment
0001-Ticket-48414-cleanAllRUV-should-clean-the-agreement-.patch

d46a0f6..11a5b1e master -> master
commit 11a5b1e412cb77a752366e352cb9d203c52b108e
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Sep 6 10:39:46 2016 -0400

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1745

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.