Launched workflow continues to relaunch on it's own infinitely

[Dobrisa]

I need some help. I created a relatively simple workflow (reused from another workflow we have) that takes a file, changes the state to Obsolete, moves it to a separate folder and starts a timer. After the timer is done, an activity is launched asking an Assignee to take some action. When that's completed, another timer starts followed by another activity (same as the first one) and then the workflow ends. 

There are no loops in the workflow. There's barely any code! The only code that exists is the "move file to folder" java code. 

Somehow every time I go to initiate this workflow it initiates and then continues to do so on its own until i disable the workflow template. Now that I know to look for this, I normally catch it after it's only initiated about 200 times or so. The issue is also that the activities sends an email and the first time this happen, Windchill sent me 1800 emails before I was able to shut down the workflow. 

Am I missing something easy here? Where else should I look to see what's causing this infinite loop? 

[Vincent-Kulak]

Can you share your workflow template ?

[Dobrisa]

This is the workflow:

The code in the "Move file to folder" is:

// Check if a PBO has been assigned to the process
if (primaryBusinessObject !=null) {
	try {
		wt.folder.Folder f = wt.folder.FolderHelper.service.getFolder( "myFolderNameGoesHere",((wt.inf.container.WTContained)primaryBusinessObject).getContainerReference());
		
		//move the PBO to the test folder
		wt.folder.FolderHelper.service.changeFolder((wt.folder.FolderEntry)primaryBusinessObject, f);
 	}
	catch ( wt.util.WTException wex ) {
 		System.out.println( "Cannot move "+ primaryBusinessObject.getDisplayIdentifier( )+" because "+ wex.getLocalizedMessage());
	}
}
else
 // if a PBO has not been assigned to the Process
 System.out.println( "Primary business object is NULL");

[Dobrisa]

[lgrant]

If you have copied a section of the workflow, it may not look like a loop but it may act like a loop. Have you also tried assigning the first action to a role?

[MikeLockwood]

Known as the "spiral of death" 🙂

I once sent 40,000 emails from Windchill from a workflow process that included email - not good.  Worth it always to test on a non-prod system not connected to email server.

Don't see anything in the code below.  Must be something else going on not shown.

Suggest commenting out all code in this robot and seeing if it still loops.

[Vincent-Kulak]

Not directly linked to OP but for email i use MailHog in test server. He prevent all modification on workflow for testing email template, notifications etc....

[imendiola]

Hi,

have you checked if the Obsolete state has the same workflow process defined in the Life Cycle template?

If this is the case, and you are doing a Set State to Obsolete in your workflow, it can be launching a new worklow instance each time.

Regards

[MikeLockwood]

Really good thought to look for this.

It absolutely drives me crazy that on first save of a new lifecycle template, the system automatically applies an additional workflow process for some states.  On landing on that state (generally caused by the workflow mapped to the first state), an additional process starts.  This can build without limit.  Useful if each state's workflow process only dumps the PBO to the next state and then ends, but death spiral if both continue in parallel.

[Dobrisa]

The life cycle template calls the workflow as a phase process. 

I had a call with PTC regarding this and we ended up adding a second state (something else) right after the state is changed to Obsolete. This didn't change the "death spiral". 

[MikeLockwood]

But did you explicitly remove any additional workflow templates mapped to any but the first state in the lifecycle template?

[Dobrisa]

This I did not do. There's only one other Phase Process template in this life cycle template and it's mapped to an unrelated state. There are no other templates in the remaining first three states. 

[BhushanNehe]

Did you clean all the entries that were started already. If you can attach the lifecycle and workflow template that will help.

Regards,

Bhushan

[Dobrisa]

The workflow is attached earlier in the thread. 

The lifecycle template is below. 

[imendiola]

Hi dobrisa,

If you only have 1 state in your lifecycle template, why do you have a set state robot in the workflow?

I think that you can remove the set state robot and probably that will solve your issue. 

Regards 

[Dobrisa]

There are multiple states in the template. I'll clarify: the "second state" was something PTC recommended I add just to go from Obsolete to something else. That something else is my second state and was intended to be just a means of getting the PBO out of the Obsolete state since the theory was that was causing the loop.

[MikeLockwood]

Glad it's solved.  May be misleading to admins reading this to make the statement to stay away from set state robots.  Either:

- use multiple workflow processes, each mapped to a different state, and none with set state robots, OR

- use a single workflow process mapped to the first state, and lots of set state robots (will never cause an infinite loop)

The first was very common and recommended in early Windchill days; the second is far more common now.

[Dobrisa]

Correct. I'm not saying that there shouldn't be "set state" robots used in the workflow. The takeaway for me was that "set state" action in Windchill will already set a state I want. If, after that, in a workflow I have a "Set State" robot that sets the same state again... there will be trouble. 

I still prefer multiple workflows myself.... It makes some things simpler but it also makes some things a bit more cumbersome. 

[Dobrisa · Accepted solution]

Problem is solved! 

In the workflow template, what was causing the infinite loop was the initial "Set state" robot. The action that kicked off the workflow is a "Set State" from any state to a resulting state of "Obsolete". In the workflow, the first set state change is on that PBO to "Obsolete" so the workflow gets re-kicked off.... forever and ever. 

PTC Tech support (Aniket Davkhar) found this and pointed it out. Removing any set state robots from the workflow is the solution since the initial "set state" action puts the PBO into the desired state as is.