#47919 ldbm_back_modify SLAPI_PLUGIN_BE_PRE_MODIFY_FN does not return even if one of the preop plugins fails.
Closed: wontfix None Opened 5 years ago by nhosoi.

If opreturn is SLAPI_PLUGIN_NOOP, it returns at the line 644, but if opreturn is non-zero (e.g., SLAPI_PLUGIN_FAILURE), it goes forward.

 389 int
 390 ldbm_back_modify( Slapi_PBlock *pb )
  [...]
 630             opreturn = plugin_call_plugins(pb, SLAPI_PLUGIN_BE_PRE_MODIFY_FN);
 631             if (opreturn ||
 632                 (slapi_pblock_get(pb, SLAPI_RESULT_CODE, &ldap_result_code) && ldap_result_code) ||
 633                 (slapi_pblock_get(pb, SLAPI_PLUGIN_OPRETURN, &opreturn) && opreturn)) {
 634                 slapi_pblock_get(pb, SLAPI_RESULT_CODE, &ldap_result_code);
 635                 slapi_pblock_get(pb, SLAPI_PLUGIN_OPRETURN, &opreturn);
 636                 if (!ldap_result_code) {
 637                     LDAPDebug0Args(LDAP_DEBUG_ANY, "ldbm_back_modify: SLAPI_PLUGIN_BE_PRE_MODIFY_FN "
 638                                "returned error but did not set SLAPI_RESULT_CODE\n");
 639                     ldap_result_code = LDAP_OPERATIONS_ERROR;
 640                 }
 641                 if (SLAPI_PLUGIN_NOOP == opreturn) {
 642                     not_an_error = 1;
 643                     rc = opreturn = LDAP_SUCCESS;
 644                     goto error_return;
 645                 } else if (!opreturn) {
 646                     opreturn = -1;
 647                     slapi_pblock_set(pb, SLAPI_PLUGIN_OPRETURN, &opreturn);
 648                 }
 649             }

Historically, the return value of plugins were just ignored and the process goes forward in the backend. But it's strictly checked now. (See SLAPI_PLUGIN_BE_PRE_{ADD,DELETE,MODRDN}_FN.) SLAPI_PLUGIN_BE_PRE_MODIFY_FN should follow the rule.


A workaround is in place but a fix is expected (as soon as possible) in 1.3.2

Reviewed by Mark (Thank you!!)

Pushed to master:
5f3aaa2..cb17381 master -> master
commit cb17381

Pushed to 389-ds-base-1.3.3:
0f29b5e..1729443 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 1729443

Pushed to 389-ds-base-1.3.2:
b2e24bb..65c73b4 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 65c73b4

Pushed to 389-ds-base-1.3.1:
c26a7b1..b721da8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit b721da8061074126db6028e819e629bc51c37784

Metadata Update from @nhosoi:
- Issue set to the milestone: 1.3.2.24

3 years ago

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

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

16 days ago

Login to comment on this ticket.

Metadata