User Task -> Script Task -> User Task = Task Query timing problem

[robojeff]

A portion of my workflow has this design:

User Task –> Script Task (synchronous) –> User Task

We have a REST client that frequently polls Activiti for the following information:

1. What is the status of my workflow?
2. What task does my user need to complete next?

When the first task shown above is completed the workflow advances to the following Script task, which executes synchronously.  It's job is to update some process instance variables that provide the status of the user's workflow (this is the information queried in request #1 described above).

While this is happening, the REST client has already made another request to query for the user's tasks.  Since the workflow has not yet advances to the next User Task, the REST client has no task to display to the user.

We're going to try changing the Script Task to execute asynchronously, but I still have concerns that this timing issue may only mask a deeper design flaw that we've created.

Is there a better workflow design strategy I should be implementing to update process instance variables on completion of a task? If I moved this logic to a Java TaskListener, would that listener be guaranteed to complete before control is returned back to the client after completing the task?

Thanks,
Jeff

[robojeff]

Update…

We've been trying to confirm if the Activiti engine blocks on a call to complete a task until the workflow reaches a subsequent User Task or the process ends.

We've moved the Groovy script code from the Script Task that sits between the two User Tasks to a ScriptExecutionListener attached to the first User Tasks's "end" event.  We put a 30 second delay at the start of the script.  When we run our unit tests we do see that completing the 1st task is a blocking call (> 30 seconds) until the ScriptExecutionListener completes its job and the next User task becomes the active step in the workflow.  However, we still are still observing a problem with our Web client requesting tasks and not getting any results.  Refreshing the page gets the results.  So somewhere we've got a race condition.  We just don't know if it's in the client or the workflow itself.  Looking at the timing of the web requests, they appear to all be in the correct sequence.

So here's what I need to know from the experts on this forum:

1. Do all TaskListeners and ExecutionListeners attached to a task's "complete" or "end" events execute on the same thread as the request to complete the task (meaning, is the client blocked until all listeners complete executing)?

2. Is the client blocked on the call to complete a task until the workflow reaches a subsequent User Task or the process ends? (I assume that any intermediate behaviors configured to execute asynchronously do not block the client).

Thank you!
Jeff