Found in a stress test:

The topology is 4 masters linked with others shaping square. M1 and M2
feed hub H1; M3 and M4 feed H2. H1 and H2 feed read-only replicas C1, C2, C3, C4.

     M1 <---> M2
     ^        ^
     |        |
     v        v
     M4 <---> M3

   M1,M2    M3,M4
     |        |
     v        v
     H1       H2

    C1, C2, C3, C4

The test used to generate agreement M1->M2, then initialize M2 on M1,
generate agreement M1->M4, then initialize M4 on M1,
generate agreement M1->H1, then initialize H1 on M1,
generate agreements M2->M1, M2->H1, M2->M3, then initialize M3 on M2
generate agreements M3->M2, M3->M4, ..., M4->M1, M4->H2, then
initialize H2 on M4
....

The problem is when initialize a consumer, the suppliers' info are passed
to the consumer and stored in the RUV. If the supplier is not a direct
one (For H2, M2 is not a direct supplier, but an indirect supplier) the
URL is stored only at the initialization time. I think when initializing
H2 on M4, M2 info was not replicated to M4. That makes RUV like this (no
replica 2, which is indirect).
rdn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff
nsds50ruv: {replicageneration} 4fbd34ab0000ffff0000
nsds50ruv: {replica 4 ldap://M4:3803}
nsds50ruv: {replica 3 ldap://M3:3802}
nsds50ruv: {replica 1 ldap://M1:3800}
ou: my_ou_2

Once this RUV is generated, following updates from M2 has no chance to set
the URL, but only sets up CSNs, which leaves "nsds50ruv: {replica 2} csn
max_csn".