Our customer has a workflow that waits for data to change and then moves it on. There are currently 1425 workflows completed or waiting of which 375 have been Terminated. There does not seem to be any particular reason why they have been terminated.
The error is caused by either of two Wait for Entry Change conditions in the workflow.
The error is "The condition entry was deleted. [username] [0650-WF0]"
The image still exists complete with any metadata already gathered.
The images are waiting on an entry change but have been terminated for no reason that we can see. The Windows Event log shows nothing for the error dates found.
There have been no upgrades/new versions for this particular workflow.
Could you please explain the error code 0650?
Question
Question
Workflow Terminating with Error 0650
Answers
This error typically occurs when an entry is deleted. When the deletion event occurs it sends this message to workflow to let it know to not wait forever.
With that being said and you saying the entry exists, lets try to figure out what else could be going on.
1) Is this workflow 9.1 or later? If so your workflow should of logged tokens. See if any are from the Wait activity.
2) Are workflows still failing or was this a one time event? If they are still failing, try adding a try catch around this activity and doing some error handling (a workaround I know).
3) Is the user mentioned in the error message an actual user or the subscriber service user?
4) Is it possible they were deleted by mistake and then restored from the recycle bin?
If you feel comfortable running database queries, you could investigate the Laserfiche server's 'activity_log' table to see what events are on any of the failing entries. These are the events that workflow checks.
so something like 'select * from activity_log where tocid1 = 12345678' look at the event column. The most common events are:
1 - create entry
2 - delete entry
3 - copy
4 - move
23 - changes
24 - restore
Alternatively, you could look at the old logs in the Workflow subscriber trace. See this help file and http://answers.laserfiche.com/questions/54118/Workflow-Subscriber-Trace-Log and
As for the mismatched activity name, this is usually just a display issue. There are some ways we could verify if the message is coming from the correct activity but its a bit of work. You could query workflow's search_error_log table for this message and then check the workflow xml (the wfx file) for the safe name of the given activity and see if they match.
Due to internal technical reasons, workflow takes the display name shown on the canvas and shortens it to a 'safe name' so the activity name 'Wait for Entry Change' typically gets condensed to 'WaitForEntryChange'. When displaying the results it has to map these names back. These safe names also have to be unique. Sometimes, this mapping can get confused due a number of issues like copy paste. We'd have to look at the actual database message and the wfx file to see if they map up.
Thank you for your replies. As it turns out, due to some recent anomalies in workflows for other entries we were too hasty to blame workflow for this error also.
Audit Trail has shown that the entries were deleted and restored again by a different user; therefore breaking the workflows.
Just goes to show you should use all the tools at your disposal.
Replies
To fill time while you wait for an answer, could you post the properties that show up on the right when you have the Wait for Entry Change selected? I would imagine that if you have the wrong Entry selected, that could lead to some confusion.
Is it possible for two different workflow instances to be waiting on the same Entry?
Hi Gareth,
Most of the workflows are OK from start to finish so the configuration is OK.
The entry IDs have not yet been acted on by any other workflow.
The Wait For Entry Change conditions are:
The workflow is waiting for the user to verify the data and change the 'Correct Data' field to 'Yes'.
The last entry in the workflow Conditions, before termination, was that this field equaled 'No'.
A support case had been created. It was determined that the entries were in fact deleted. As for the entries that still appeared to be present in the repository, Audit Trail confirmed that the entries had in fact been deleted and then later restored from the recycle bin at a later point in time.