Workflow stops processing at run script activity - log states: "After running a sequence of activities we expected a 'last executing' record to predict the future stages from"

[DBeckers]

Hi Community,

Within our workflow, we have a run script activity, that triggers a powershell script on a mid server.
When we order one item the workflow works as expected.

So, if we order 30 items at once (over the add to cart function), all workflows start properly. At some point, several workflows seem to be stuck. All at the same run script activity, but not all of them, maybe 10 of 30 items will be processed as expected.

I've already re-created the script activity, as I thought it might be corrupted, but that doesn't fix it.

The only hint I've found was in the workflow context message:
After running a sequence of activities we expected a 'last executing' record to predict the future stages from

If I nudge the workflow, this message suddenly gets added to the workflow log again.

So, log messages within the run script activity also don't trigger, which seems, that the activity does not start at all.

Does anyone encountered the same problem before?
I can't find any information regarding this message and that are applicable to my topic. 

Any help would be appreciated.

Regards Dominik

[Allen Andreas]

Hi,

Workflow scripts and activities in general can get a little wonky. If they process too fast or too often, it'll lock it up.

I'd recommend to try adding a 1 second timer activity before the runscript activity in your workflow and see if that helps. The edge case situation here though is that all 30 will hit the same 1 second timer, so the same results may happen, but in my experience, a timer activity helps.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[DBeckers]

Hi Allen,

thanks for your reply.

Since we always set a timer at the beginning of the workflows (with a scripted rand number between 10 - 90 seconds, because the screen will be blocked until the script finished it's execution), it does not fix the problem. Even though, when I place the timer directly before the run script activity.

This is what surprises me, because we have ohter workflows, which are constructed the same way and everything works fine (talking about 500 simultaneous RITMs).
Also the script is executed correctly on the mid server and wants to return values, but these values don't seem to be processed by SNOW, because the workflow is stuck.

This leads me to another question:
Is it possible to wait for a workflow to complete for a RITM, before it proceeds with another one?

Best regards
Dominik

[Inactive_Use945]

i have a similar situation too.

My workflow executes well once or twice and then starts acting up. If i checkout and publish workflow without doing any sort of changes, it starts working well for one or two times.

I tried checking the Run Script activity and everything looks Ok. The run script activity is supposed to trigger a REST message with some gs.log at various steps. Step 1 gs.log shows up in the logs and the rest dont show up. REST message execution gets marked as failed and the workflow proceeds.

[abhisheksolanki]

This is an old thread but I noticed this message in the Workflow Log of a Workflow Context that was stuck. In fact, every time I clicked on Nudge, this message would be dumped. As the message suggests, the Workflow Executing Activities tab was empty i.e. no activity was running.

In my case, the Workflow was stuck at a second Approval - User activity since its result was 'skipped' but the Conditions were only coded to accept '', 'approved', 'rejected' and 'cancelled'. The developers would fix it eventually but the question was how to nudge the existing requests / workflows ahead. This is the workaround I came up with up after a day of trial and error - 

1. Create a record in wf_executing as below -
var wfExecuting = new GlideRecord('wf_executing');
wfExecuting.initialize();
wfExecuting.activity = '99f53e21dbd064d024c89806b9961955'; // Sys ID of the last or stuck wf_activity 
wfExecuting.activity_index = 9;//The sequence of the above activity in the relevant wf_context
wfExecuting.context = '4e1bf043dbb0ec147805c23813961951';//Sys ID of wf_context record
wfExecuting.is_parent = false;//Not sure but existing wf_executing records had this. So that's what I went with
wfExecuting.notify_termination = false;//Not sure but existing wf_executing records had this. So that's what I went with
wfExecuting.previous_activity = '921bf043dbb0ec147805c23813961966'; // Sys ID of previous wf_history record in the relevant wf_context
wfExecuting.started = '2020-12-04 15:13:12';
wfExecuting.state = 'waiting';//Not sure but existing wf_executing records had this. So that's what I went with
wfExecuting.workflow_version = '19f5fa21dbd064d024c89806b9961913'; // Sys ID of wf_workflow_version
var id = wfExecuting.insert();
gs.print(id);

2. Open the wf_context record or refresh it. You should now see a Workflow Executing Activities record. Personalize the list and select Scratchpad and Output Data
a) Key in Output Data as {}
b) Scratchpad as {"approval_ids":["561bf043dbb0ec147805c23813961968"]}
That is the sys_id of the first sysapprover_approval record which had actually been approved. So, I knew that if I made the second Approval - User activity look at this, it should return 'approved' and proceed. You may need to improvise depending on where your workflow was last stuck. Look at existing wf_executing records for the same Workflow version.

3. On the wf_context record click on Nudge. The workflow came to life and actually nudged ahead.