Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-6156

Multi-valued mail attribute causes reconciliation to abort without accurately auditing the failure cause




      Using a default provisioner configuration (using sample2b), which defines mail as a single valued attribute; One of the entries has a mail attribute with two values. During a reconciliation run, for this entry, this exception is thrown :

      2016-07-04 17:47:57:120 WARN Incorrect schema configuration. Expecting mail attribute to be single but it has multi value. [AttributeInfoHelper]Failed to read target object
      org.forgerock.json.resource.ConflictException: The mail attribute is not single value attribute.
      	at org.forgerock.json.resource.ResourceException.newResourceException(ResourceException.java:230)
      	at org.forgerock.openidm.provisioner.openicf.impl.OpenICFProvisionerService$ObjectClassResourceProvider.handleRead(OpenICFProvisionerService.java:1509)
      	at org.forgerock.openidm.provisioner.openicf.impl.OpenICFProvisionerService$ObjectClassRequestHandler.handleRead(OpenICFProvisionerService.java:1048)

      The entire reconciliation is cancelled, and there is no trace of the object that caused the error in the log file, or audit logs (recon.csv). The expectation is that when recon aborts:

      • The summary entry which is written to the audit log should accurately reflect the number of entries processed.
      • The sync operation which triggered the failure (meaning the entry which contained multiple-values for a multi-valued attribute) should be accurately auditted and include the failure cause.

      Keeping the following from the original bug report for posterity. The issue of reconciliation aborting will not be addressed as that is the expected behavior (see comments).

      The error also exists in 3.1, but it was not stopping the reconciliation.

      The workaround is to change the mail definition to be an array.

      However, this error is basically caused by an entry that does not conform to the expected format and is not intrinsic to the connector (such as a loss of network connection), and therefore, should not stop the reconciliation, and report the failure in the reconciliation report.


          Issue Links



              cgdrake Chris Drake
              patrickdiligent patrick diligent
              1 Vote for this issue
              9 Start watching this issue