Hi Ziyan,

First, to answer your question, 'a supervisor leaves' does indeed refer to that user no longer being a valid Forms user.

Regarding the error itself, my frustration got the better of me, and had thought the termination was related to the Supervisor notification due to the two coinciding.  What appears to be happening, instead, is that somehow Forms is calling the Timer event attached to the user task before calling the task itself.  To be clear, this is not a separated timer event, but a subordinate timer assigned to the task, and a non-interrupting one at that.

When the timer expires, it throws a Routing error. I'm thinking that's due to the timer as an individual event not really existing, but I don't have anything to back that up with.  As a potential solution, I have deleted and re-created the timer event, then initiated a new instance of the Forms process that goes to that user task.  I will know tomorrow if that worked.

It did not work.  I will post an update if I  find a solution, as well as updating the question / description itself.

Hi Sean,

So the symptom of the terminated instance is that, a boundary timer catch event starts before the its user task starts? What is the configuration of the timer then? 

Hi Ziyan,

Yes, this thing is causing me no end of trouble.  At this point, I have little choice but to just delete the timer event entirely, since it keeps causing our Forms process to terminate, and Incidents will go unreported if I'm not watching carefully to make sure each terminated instance gets restored.

My most recent attempt at fixing this issue consisted of these steps:
 

1. Delete the Timer Catch event on the Originator task
2. Bring my test instance through the related user step WITHOUT the timer attached
3. Verify that the timer didn’t show up in the Monitor history this time (it didn’t)
4. Re-submit the Form to move it back to the ‘downstream’ administrative task
5. Restore the timer event on the Originator task
6. Send the task back to the originator again
7. See if the timer event would behave itself this time (it did not – still terminated)

I am attaching screenshots of the timer event / configuration, as well as the Monitor history. If you have any thoughts on how I can fix this that would be really great, since I'm not feeling a lot of faith towards timer events right now.  Even if the answer is "you're an idiot, just change this little thing" I would rather feel stupid than have tasks that terminate whenever they hit a timer!

The instance history shows the timer was successfully executed and went to next step, so it seems less likely to me that it is the timer that terminated the user task. 

Just to confirm, the interrupting signal boundary event was not triggered in that case, right? Could you share the detailed instance error around 7/2/2022 4:49:36 PM of that instance?