389-ds-base

#48804 During replication of modrdn, the replication fails to continue the session after init.
Closed: wontfix Opened by firstyear.

Closed: wontfix
Reopen Issue

As a result of #47788, we no longer skip failing changes, but continue to send them.

However, this conflicts with part of the urp.

If during an init between master A to B, there is a modrdn in the changelog it can cause this issue.

After the init from A to B is complete, the CSN of B, is not set to the CSN of A. A replication is triggered, and the changelog is played. This causes some events to be replayed that have already been applied. In the case of a modrdn, this causes a failure to apply the change.

But due to #47788, this failure cannot be skipped, so this change is sent repeatedly. This causes B to no longer receive any updates from A.

A fix for this exists in 1.3.x as part of #499. However, we may need to be careful in it's application to 1.2.11.

In summary, the fault is in the inability for a modrdn to be applied in an idempotent way.

Let me double-check...
* Is this issue in the 1.2.11 branch only?
* If so, the problem is it is too hard to fix it since backporting the #499 change to the 1.2.11 branch is not straightforward?
* Do we have a reproducer of the bug? Is it something like issuing simultaneous modrdn to multiple masters and causing a conflict among them?
  • Is this issue in the 1.2.11 branch only?

Yes, 1.2.11 only.

  • If so, the problem is it is too hard to fix it since backporting the #499 change to the 1.2.11 branch is not straightforward?

I am not sure: I'm hoping someone with more knowledge of this area can tell me if 499 would be hard to backport or not.

  • Do we have a reproducer of the bug? Is it something like issuing simultaneous modrdn to multiple masters and causing a conflict among them?

Not yet.

From the user:

{{{
1- have a supplier/consumer setup (consumer should be running 1.2.11 master branch).
2- fill your supplier's changelog with many modrdn ops.
3- init your consumer (initiate a total update).

After your consumer is fully initialised, you will notice it's running some already applied changes again and it will fail on the modrdn ops and will be stuck on repeating this change.
}}}

I think the user had a chance to try this test build...
https://copr.fedorainfracloud.org/coprs/nhosoi/389-ds-base-test-el6/package/389-ds-base/

Could there be any feedback from them? Thanks!

I'm asking them again to test.

No need for this to be continued

Metadata Update from @firstyear:
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

Metadata Update from @vashirov:
- Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)

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/1864

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
None
Low
needinfo
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.