Copyright year is wrong, but that's not the end of the world :)

Probably can remove this comment :)

And this should be acomment, not a multi-line un-assigned string :)

I'm wondering if there is a way to do this without getEntry, because you clearly need the SCOPE_SUBTREE on the search. Looking at lib389, I think the answer is "it's not possible today", so perhaps this is a bug for lib389 as well?

You probably don't want the try/except here, just let the error raise up because it will stop the test anyway

with pytest.raises(ldap.NO_SUCH_OBJECT):
topology_st.standalone. ....

May be a better pattern here.

Just a few lib389 comments, but the .c change is reasonable to me.

Thinking about this, perhaps could this have been the reason for the failures with filter optimisation enabled?

I'm wondering if there is a way to do this without getEntry, because you clearly need the SCOPE_SUBTREE on the search. Looking at lib389, I think the answer is "it's not possible today", so perhaps this is a bug for lib389 as well?

I would lov to use something different, but it looks like search_s is being deprecated without a proper replacement. In my opinion we need a generic search method for the server, not for a specific entry OC, and it should be able to return, No, One, many entries and let the caller decide what is right, not except on no such objet or only return the first entry

Thinking about this, perhaps could this have been the reason for the failures with filter optimisation enabled?

I do not recall all the issues, this might be a good cause. But thee were also issues with acis, when the rewritten filter was evaluated and there was no right to the parentid attribute

with pytest.raises(ldap.NO_SUCH_OBJECT):
topology_st.standalone. ....
May be a better pattern here.

But hoe do I catch the exception ? Unfortunately getEntry raises an exception if no entry is found, but that is the expected result, so the exception is the GOOD case

We got an agreement from @lkrispen, @firstyear and myself (https://pagure.io/389-ds-base/issue/50234#comment-556694) that the fix part is good.

I understand that there is potential pending concerns regarding the testcase but it works.
Considering that this bug is important and we can rework the testcase later, you have my ACK to merge it

@lkrispen Yes, with pytest.raises() is saying "I expect an exception of this type to be raised here", and if that exception is not raised an assertion error is raised to say "well, I wanted an exception, but it did not happen".

Does that clarify what the api does?

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3294

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.