If a replication agreement is created with the autoinit flag the total protocol is started, but if it fails it switches to incremntal and can loop forever in comparing the generationID. This is becaus next state is set to INCREMENTAl and the result of the total run is not checked.
rp->next_state = STATE_PERFORMING_INCREMENTAL_UPDATE; ..... rp->prp_total->run(rp->prp_total); agmt_replica_init_done (agmt);
there is a commment in total update:
rc = acquire_replica (prp, REPL_NSDS50_TOTAL_PROTOCOL_OID, NULL /* ruv */); /* We never retry total protocol, even in case a transient error. This is because if somebody already updated the replica we don't want to do it again */
This is reasonable in some cases, but if the genrationID is still different, we know that no other server did update the replica. Especially if a new server is added and we want to initialize it, the total update request should not get lost
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1258610
attachment 0001-Ticket-48255-total-update-request-can-be-lost.patch
The patch 0001-Ticket-48255-total-update-request-can-be-lost.patch is pushed to the git repository and included in the 389-ds-base-1.3.4.4 build. Hence closing this ticket.
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.4.4
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/1586
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.