modrdn operation that fails in backend txn plugin can corrupt entry cache

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50238

• Created at 2019-02-22 19:35:20 by mreynolds (@mreynolds389)
• Closed at 2019-02-26 15:34:07 as fixed
• Assigned to mreynolds (@mreynolds389)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1680245

---

Issue Description

I can only reproduce the issue in a IPA deployment, but if modrdn operation fails (via memberOf plugin failing) the original entry (before the modrdn attempt) is removed from the cache, and can no longer be updated.

The issue is that we replace the original cache entry with the new modrdn'ed entry, but if we fail in backend txn postop plugins we do not undo that swap.

Package Version and Platform

Steps to reproduce

Actual results

Expected results

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-02-22 19:53:53

#3298

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-02-22 19:53:53

Metadata Update from @mreynolds389:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to review

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-02-23 13:15:51

Metadata Update from @mreynolds389:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1680245

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-02-26 15:34:07

commit b30295a

ea24c43..a063984 389-ds-base-1.4.0 -> 389-ds-base-1.4.0

70117f5..1bdf627 389-ds-base-1.3.9 -> 389-ds-base-1.3.9

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-02-26 15:34:08

Metadata Update from @mreynolds389:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)