Add CI test, but I can not reproduce the original issue where the original entry is not in the cache after the failed modrdn. but the CI test found a different bug that is now also fixed: without the fix the CI test leaves the failed modrdn entry in the cache.

So with the fix the failed modrdn entry is not in the cache, and the original entry is in the cache. I just can't reproduce the issue where the original entry is not in the cache after the failed modrdn (at least not outside of an IPA deployment).

Don't need to catch this, just let the exception raise.

with pytest.raises(ldap.OBJECTCLASS_VIOLATION)
do this thing

with pytest.raises ...

Okay, that's fine. Some comments on the testcase

The test reaches that point and fails here... 389-ds-base-1.4.1.1-20190225gitf0e46d155.fc29.x86_64

The test reaches that point and fails here... 389-ds-base-1.4.1.1-20190225gitf0e46d155.fc29.x86_64

Sorry this PR assumes my previous PR was applied:

https://pagure.io/389-ds-base/pull-request/50237

When it is, the correct error code is caught... I'll get that other PR fixed, and reviewed again, then I we should retest this CI test

It looks to me the cache_replace will do similar job as CACHE_RETURN did on 'ec'.
In addition it adds back 'e' (old entry) into the entry cache. Is it what was missing ('e' in entry cache) and explaining the crash ?

It looks to me the cache_replace will do similar job as CACHE_RETURN did on 'ec'.
In addition it adds back 'e' (old entry) into the entry cache. Is it what was missing ('e' in entry cache) and explaining the crash ?

This does not fix the crash because I can not reproduce the crash. And that is actually a completely different issue.

The issue here is that a failed modrdn leaves the original entry out of the cache, and the failed mordrdn in its place. We need to revert it

Thanks @mreynolds for the explanation. I think the previous code should have remove the failed modrdn from the cache but I agree it is good to return the original in the entry cache.
the patch looks okay to me and you have my ACK

@mreynolds
I can confirm that this PR & #50237 fixed my issue.

Thank you

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

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.