Optimistic locking enables both the operators to open the case. No lock is obtained when the case is opened. The lock occurs when the user clicks Submit. When two operators are working on the same case, the changes to the case are made by whoever submits the case first.
The second operator receives a message with the first operator’s name and the time of the change. Also there is a refresh button that allows the second operator to get the new changes made by the first operator. The second operator’s changes are not applied until they click refresh and submit their action after the refresh.
So ideally "Flow not at task " error should not come.
I am curious to know few more things about this :
1. Who is getting this error ? First user or second user or both ?
2. Are you seeing any interesting entry in the log which tells about some exception ? Worth checking it.
3, Have you run tracer and see the entries there ? Are you seeing any error coming in the tracer ?
Two users performing immediately on same assignment, would getting this error 'Flow Not at Task'. And if the same two users performing with gap(in seconds) on same assignment we are not getting this error but as you said getting that error(The second operator receives a message with the first operator’s name and the time of the change. Also there is a refresh button that allows the second operator to get the new changes made by the first operator>>not exactly this error, but related error).
and to your questions:
1. Who is getting this error ? First user or second user or both : Second user/Some times both
2. Are you seeing any interesting entry in the log which tells about some exception ? Worth checking it: Will update you soon
3, Have you run tracer and see the entries there ? Are you seeing any error coming in the tracer: Not able to trace because if we trace, assignment will get time(gap) while executing so that this error is not coming and traced like this, two users hitting at same time on single assignment.
and read those two articles and those are not related to this scenario.
Unfortunately not logging anything related to this error , i am trying to get more info on this. And i have raised SR on this, the Pega saying, once the discussion confirms that the issue with product, then they will work on this one .
The "flow not at task" should never occur, since it means one of the items in the pxFlow table in the work object has a pxAssignmentKey whose assignment object indicates a task (which basically means a shape in the flow diagram) that is different than the task indicated on the item in the pxFlow table.
Do you have a reproducible scenario that takes a work object that is not having this problem and converts it to one that does have the problem ? Or is it intermittent.
One thing to check for, is look through your code, by which I mean your flow action pre and post activities, your flow utility shape activities, your pyDefault activity, and your SLA activities, and see if you have any commits. You should not. If you do, they should be removed since that could contribute to the "flow not at task" issue. Also, if you have any obj-saves with "write now" checkmark or obj-deletes with "immediate" checkmark, and their target object is the primary work object or assignment object, those should be removed as well.
What ever you said above, we are not doing that like committing obj-save with write now option, but still some times its getting like two users performing one single assignment. But finally we asked them to refresh if the assignment stays open for a while if there is a chance to perform this assignment by different user(work around solution) and normally we have OOTB behavior like if some one performs one assignment and another user trying to perform same assignment we will get pop up message saying..this assignment already performed, please refresh some thing like this but in this case its not happening and we could not trace and there is no logs. But finally as we suggested, untill now there is no issues.