389-ds-base

#49619 adjustment of csn_generator can fail so next generated csn can be equal to the most recent one received
Closed: wontfix by mreynolds. Opened by tbordaz.

Closed: wontfix
Reopen Issue

Issue Description

On consumer side csn_generator ajustment occurs (let CSN = highest known csn)

  • when a replication session starts
  • when a csn is generated locally and than csn is <= CSN

During adjustment, in the case

  • there is no remote/local offset (time change)
  • the current_time on the consumer is identical to CSN

Then next locally generated csn will only differ with seqnum

The seqnum of the csn_generator is increased only if CSN.seqnum is larger
than the csn_generator one.
In case of egality, it remains unchanged.

The consequence is that the next locally generated csn will be identical to CSN (except for the RID). So even after csn_generator adjustment, csn_generator may create csn that are not larger than the CSN

Package Version and Platform

All versions

Steps to reproduce

  1. see FREEIPA-921

This is a timing issue, so it is not systematic. Now on the test systems it happens one time out of two.

Actual results

The generated csn can be lower than the highest known csn and urp can order operations in the opposite way.

Expected results

generated csn should strictly be larger than the most recent one received

Metadata Update from @tbordaz:
- Custom field component adjusted to None
- Custom field origin adjusted to IPA
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

0001-Ticket-49619-adjustment-of-csn_generator-can-fail-so.patch

The attached patch is still under tests.
Before the failure happened 1 time out of 2.
With the patch, it runs successfully 10 times (continuing the tests up to 20 runs)

Metadata Update from @tbordaz:
- Custom field reviewstatus adjusted to review (was: None)

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to ack (was: review)

@mreynolds thanks for the review. The tests complete successfully so I think it is okay to push the patch. Now it has not been triaged yet. It applies to all branches. Is it okay to push it master/1.3.7/1.3.6/1.2.11 ?

@mreynolds thanks for the review. The tests complete successfully so I think it is okay to push the patch. Now it has not been triaged yet. It applies to all branches. Is it okay to push it master/1.3.7/1.3.6/1.2.11 ?

yes that is fine

To ssh://pagure.io/389-ds-base.git
5ba01818f..5bfe2a3e3 master -> master
To ssh://pagure.io/389-ds-base.git
485cf0c65..d5e2f7494 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
To ssh://pagure.io/389-ds-base.git
73ba03931..92c4c2a68 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

Finally not committed to 1.2.11

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1559945

Issue linked to Bugzilla: Bug 1559945

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0

This bug introduced a regression tracked with https://pagure.io/389-ds-base/issue/49631

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

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

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: fixed)
Metadata
None
None
None
None
IPA
ack
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.