AEM 6.4 Assets | DAM Update Workflow fails but shows as RUNNING
As per default AEM behaviour, when uploading/updating an Asset, DAM Update Asset workflow is triggered - in our setup this includes a S7 upload step.
Problem:
In some cases we get an exception such as
- repository conflict exception for an asset, or
- S7 timeout exception as shown below
com.adobe.granite.workflow.WorkflowException: --Dynamic Media asset process failed. Please contact your system administrator.-- /content/dam/myasset.jpg
at com.day.cq.workflow.compatibility.CQWorkflowExtProcessProxy.handleResult(CQWorkflowExtProcessProxy.java:99)
at com.adobe.granite.workflow.core.util.WEPProxyHolder.handleResult(WEPProxyHolder.java:50)
at com.adobe.granite.workflow.core.job.ExternalProcessPollingHandler.process(ExternalProcessPollingHandler.java:129)
at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.day.cq.dam.scene7.api.model.IpsApiException: org.apache.http.NoHttpResponseException: s7sps3apissl.scene7.com:443 failed to respond
at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.makeRequest(Scene7APIClientImpl.java:356)
at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.searchAssets(Scene7APIClientImpl.java:1178)
at com.day.cq.dam.scene7.impl.Scene7ServiceImpl.searchAssetsByFilename(Scene7ServiceImpl.java:489)
at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.getAssetHandle(Scene7UploadProcess.java:871)
at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.handleSingleAssetUploadResult(Scene7UploadProcess.java:1078)
at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.handleResult(Scene7UploadProcess.java:1020)
at com.day.cq.workflow.compatibility.CQWorkflowExtProcessProxy.handleResult(CQWorkflowExtProcessProxy.java:97)
... 9 more
Caused by: org.apache.http.NoHttpResponseException: s7sps3apissl.scene7.com:443 failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.getResponse(Scene7APIClientImpl.java:424)
at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.makeRequest(Scene7APIClientImpl.java:342)
... 15 more
In such cases, the failure shows as an inbox notification (thus allowing us to manually identify such failures and retry the step).
However, the workflow instance itself shows as "Running" instead of "Failed", which
- imho is a bit counter-intuitive
- we cannot effectively get such failed workflow instances via AEM Workflow REST API
The above can occur for a failure at any step, the repo conflict is the most common issue we get however.
Question(s):
- is there a workaround for this, to allow the aforementioned API usage?
- is there an effective (ideally OOTB) way to retry the failed step?
Thank you in advance for your help.