Make sure you don't have any obj-save or obj-delete calls that targets the work object or the assignment page and that also use the "write now" or "immediate" checkmarks to commit the operation.

Also, make sure you don't have any "commit" calls.  The core layer will handle committing of your work.

If you have any of the above extra calls, and if the core layer's commit fails for some reason, it will attempt to roll back but will not be able to since your extra commit has already occurred.

/Eric

Is this reproducible at will, or just occasional without a recipe for producing it ?

Assuming only occasional, look at the history on the work object to know what flows and flow actions led up to the failure.  That tells you what sorts of code to look for.

When the issue occurs, what shows up in pega log file at that time ?  Make sure you're looking on correct node if it's a multi node system.

The reason I asked about the extra commits is that under the hood, the old assignment is deleted (deferred) then later pxFlow is updated to remove the entry, then it is all committed.  If there is an error during commit, it is rolled back.  Normally, this roll back undeletes the assignment so that the pxFlow still refers to the assignment.   But are you saying pxFlow refers to a nonexistent assignment ?  That could be because the assignment deletion got committed instead of just deferred.

/Eric