We have a JDBC connector that executes a prepared statement upon LCM disable. It usually works fine but on occasion during processing LCM changes to this connector, we encounter failed with the error: SQLRecoverableException: I/O Exception: Connection reset. This error is configured in retryable errors on the application config but it is not retrying. The other retryable errors we have tested do retry, however,this one will not. The identity prior to and immediately following the identity that encountered the error is processed successfully. Any idea how we can get this to retry before failing or why it is failing to retry on this particular error?
So that can depend on which “retry” mechanism you’re using for provisioning. The preferred (and most commonly used) is the “Provision with Retries” workflow subprocess (which is what the LCM Provisioning and most other OOB provisioning workflows use), but if you’re invoking the provisioner directly (i.e. via Java/Beanshell), you may be relying on the legacy Request object retries mechanism or some of the built-in connector retriable errors.
So we have provision with retries set in the LCM workflow but also added retryable errors in the application xml in hopes of getting this specific error to retry. We have tested with other values and they retry fine, but this and only this error fails to retry. Due to the sporadic nature and inability to force the specific error, testing it is very difficult.
As this is something that should be OOB-supported behavior, I’d suggest trying to capture some logs (will be difficult given the unpredictable nature) and open a Sailpoint Support case.