Email approval failed with state error in External Authorisation node

[Berto2002]

I have just had a workflow fail with this error. I couldn't see anything wrong in the BPM so I just clicked the restart on the user interface and it worked.

This is the second time I've seen this; the last one about a month ago.

Is there an instability in the email platform in the background?

From my side, I am unable to "see delivery log for message 19530"...

08-09-2022 12:00

0.000007s INFO Workflow processing started, processId=BPM20220906000003 workflow=com.hornbill.servicemanager/sbc-hardware-request (revision=69, type=businessProcess) 0.000014s INFO Process Execute contextSize=47862 reason=erResumeEmailApproval, nodeId=emailApproval-2b48ba32 0.000236s INFO Called by: bpm/externalApprovalSetState (host=lon-p01-node2) 0.000242s INFO Transaction ID: f722517cf37f4c89bf3af1431f7dd708 (calledBy=*) 0.092766s INFO Process Wakeup/Check event 'Send External Authorisation request to Other Approver' (id=emailApproval-2b48ba32, type=ExtranlApproval) 0.100717s INFO Execution session is '20040320$sys_init', user is 'SYS_INIT' 0.100720s INFO Execution reason is 'erResumeEmailApproval' 0.100758s INFO Execution Step: currentStage='stage-e19670cf', currentNode='emailApproval-2b48ba32', suspended='true' 0.109159s INFO External Approval State: error 0.109168s ERROR External Approval Error Message: ERROR: Unable to deliver message, see delivery log for message 19530 0.113262s INFO Unsuspending process at node 'Send External Authorisation request to Other Approver' (id=emailApproval-2b48ba32) 0.113334s ERROR Execution Failed: Email Approval failed with state error 0.148540s INFO Workflow processing complete

[Victor]

@Berto2002 not a very helpful message there... these are direct outbound emails, there is no practical way to make use of the message ID anywhere in the UI to locate this message and review the delivery logs... something we would need to look into.

Meanwhile, if needed, the delivery logs for this type of emails are stored in h_msg_direct_delivery_log table. If you filter on message ID (which in this occasion is 19530) you would get details of the delivery and if it failed, why it failed. 

[Berto2002]

Thank you Victor I have found the log that you suggested so I will document this in our procedure for handling errors:

select * from h_msg_direct_delivery_log
where h_msg_id = 19530

[Berto2002]

@Victor Two minutes after the error was reported, the system retried ("Delivery will be re-attempted at 2022-09-08 11:01:48Z (1 minutes), attempt 1/9") and was successful in sending the email, giving the output of "Message delivered to target recipient OK" in h_log column. I guess my observation here is that the email sending engine is coded to try up to 9 times but the user interface is designed to fail permanently on the first. It would seem ideal to alter the UI behaviour so that the error only displays at the end of the 9th attempt if that ends in failure; rather than failing on the 1st attempt.

[Steve Giller]

2 hours ago, Berto2002 said:

Two minutes after the error was reported, the system retried ... and was successful in sending the email

 

23 hours ago, Berto2002 said:

I couldn't see anything wrong in the BPM so I just clicked the restart on the user interface and it worked.

It is likely that this is what triggered the resend.