Setting of nsIndexIDListScanLimit like 'limit=2 limit=3' are detected and logged in error logs. But the invalid value is successfully applied in the config entry and the operation itself is successful.
The impact is limited because the index will be used following idlistscanlimit rather than invalid definition nsIndexIDListScanLimit
Any version > 1.2.11
operation succeeds and invalid value is set in the index config entry
operation should fail and only valid value must be set in the index config entry
Hmmm, should we have better checking of valid idlistscanlimit values in the code then?
Metadata Update from @firstyear: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
scanlimit is used to switch to ALLID during index lookup (if an indexed filter component returns more candidates than the specified limit)
This limit can be defined at system level (nsslapd-idlistscanlimit), at index level (nsIndexIDListScanLimit) or at bound user level (nsIDListScanLimit). The way the values are applied/checked at system/user level looks good enough to me. The ticket is specifically for index level (nsIndexIDListScanLimit) where invalid values are accepted/applied but ignored.
When you say ignored, they are not used at all if set on a user level?
@firstyear, ALLID is enforced with increasing priority system_level < user_level < index_level.
if an operation sets an index_level (nsIndexIDListScanLimit) that is invalid, the operation succeeds, the invalid value will be present in the index config entry, but at run time the invalid value is ignored. So the server fallback to user_level if any, else to system_level
Ahhhhh I see what you mean now. Okay. So what do you plan to do to fix this? Improve validation of the index level idlscanlimit?
The validation is already in place but error handling is not locally propagated and also not managed at upper level.
Metadata Update from @tbordaz: - Issue assigned to tbordaz
Metadata Update from @vashirov: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1672574
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.1
Metadata Update from @mreynolds: - Issue priority set to: normal - Issue set to the milestone: 1.4.3 (was: 1.4.1)
Metadata Update from @spichugi: - Issue assigned to spichugi (was: tbordaz)
https://pagure.io/389-ds-base/pull-request/51056
Metadata Update from @spichugi: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
23b4d72..00c4760 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
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/3260
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.