New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
retroCL may miss some update if internal add fails #1133
Comments
Comment from tbordaz (@tbordaz) at 2014-05-19 22:31:07 The previous test case can be confusing as we may think some updates are skipped because some values are replaced. Here a more direct test case:
|
Comment from mreynolds (@mreynolds389) at 2014-06-23 22:59:20 This has been addressed via ticket: https://fedorahosted.org/389/ticket/47810 Verified that if a retrocl update fails, so does the originating operation. |
Comment from mreynolds (@mreynolds389) at 2017-02-11 23:00:10 Metadata Update from @mreynolds389:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47802
retrocl_postob returns success (0) even if write_replog_db fails. So if RetroCL is enabled, it is called in postop of a MODIFY (for example). The changenumber is not written in 'cn=changelog' (in case of internal failure), but the original MODIFY succeeds.
So an update is written in the original database but not in the cn=changelog.
I reproduce this attaching a debugger and making 'write_replog_db' fail.
I was testing a fix for https://fedorahosted.org/389/ticket/47797. The fix, is to catch a DB_DEADLOCK and prevent a deadlock that is quite easy to reproduce with freeipa unit tests. This fix allows an internal ADD to fail if it encounters a DB_DEADLOCK. The consequence is that the update of the retroCL fails but not the original MOD.
The text was updated successfully, but these errors were encountered: