-
Bug
-
Resolution: Done-Errata
-
Major
-
rhel-10.0.beta
-
389-ds-base-3.0.4-3.el10
-
No
-
Important
-
EasyFix
-
rhel-sst-idm-ds
-
ssg_idm
-
28
-
29
-
0
-
QE ack, Dev ack
-
False
-
-
None
-
None
-
Approved Exception
-
Pass
-
Automated
-
Release Note Not Required
-
None
What were you trying to do that didn't work?
A reindex (online or offline) task has no effect if the type (like 'eq') of the reindex is specified.
What is the impact of this issue to you?
The index being invalid, the directory server returns invalid results
Please provide the package NVR for which the bug is seen:
It was detected in upstream tests
How reproducible is this bug?:
Yes systematically but it is difficult to detect as you need to know what should be the content of the indexed attribute database to notice that the content differs
Steps to reproduce
Testcase is provided upstream
Expected results
The indexed attribute database should contain key/value
Actual results
The index does not contain all the key/value
- links to
-
RHSA-2024:132671
389-ds-base security, bug fix and enhancement update
- mentioned on
[RHEL-58070] lmdb reindex is broken if index type is specified
=============================================================================================== test session starts ================================================================================================ platform linux -- Python 3.12.5, pytest-7.4.3, pluggy-1.3.0 -- /usr/bin/python3 cachedir: .pytest_cache 389-ds-base: 3.0.4-3.el10 nss: 3.101.0-6.el10 nspr: 4.35.0-27.el10 openldap: 2.6.7-5.el10 cyrus-sasl: not installed FIPS: disabled rootdir: /root/ds/dirsrvtests configfile: pytest.ini collected 1 itemdirsrvtests/tests/suites/indexes/regression_test.py::test_reindex_task_with_type PASSED [100%]========================================================================================== 1 passed, 3 warnings in 53.50s ==========================================================================================
Test passed, marking PT:PASS
The release blocker/exception task has completed successfully and your blocker/exception request has been set as Approved Exception. Please plan/complete this work accordingly.
Viktor Ashirov mentioned this issue in a commit of Red Hat / Red Hat Enterprise Linux / rpms / 389-ds-base: