Bug 1125079 - Task status doesn't rollback if exception is thrown from taskService.start() when executing TaskServiceEntryPointImpl#claimBatch()
Summary: Task status doesn't rollback if exception is thrown from taskService.start() ...
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Core
Version: 6.0.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ER4
: 6.1.0
Assignee: Maciej Swiderski
QA Contact: Marek Baluch
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-31 03:37 UTC by Lyle Wang
Modified: 2018-12-06 17:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
reproducer including: 1) mvn project "01135268"; 2) custom eap module; 3) process def. for BPMS (21.54 KB, application/zip)
2014-07-31 03:37 UTC, Lyle Wang
no flags Details
reproducer-bpm-suite-6.1.0.ER4.zip (81.26 KB, application/zip)
2015-02-11 11:09 UTC, Jiri Svitak
no flags Details


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPM-4410 Major Open Task status doesn't rollback if exception is thrown from taskService.start() when executing TaskServiceEntryPointImpl#cl... 2018-09-17 11:04:33 UTC

Description Lyle Wang 2014-07-31 03:37:39 UTC
Created attachment 922808 [details]
reproducer including: 1) mvn project "01135268"; 2) custom eap module; 3) process def. for BPMS

Description of problem:

When a group member claims a taks in business-central, TaskServiceEntryPointImpl#claimBatch() is executed:

    public void claimBatch(List<Long> taskIds, String user) {
        for (Long taskId : taskIds) {
            taskService.claim(taskId, user);
            taskService.start(taskId, user);
        }
    }

After taskService.claim(taskId, user), the task status changes to "Reserved".
And if an exception is thrown in taskService.start(taskId, user) , the task status will not be changed back to "Ready" (it will stay "Reserved")

In my testing scenario, the exception thrown from taskService.start() is: org.jbpm.services.task.exception.PermissionDeniedException



How reproducible:

Always


Steps to Reproduce:
There should be other more simple / general ways to reproduce the issue, but I'll just use the reproducer from the customer support case. 

In this case a custom UserGroupCallback is implemented. The custom UserGroupCallback returns inconsistent user/group data intentionally (gives 'false' when checking user existance, but gives some group ids when retrieve user group info.)

So the user can see the task and can click the 'claim' button, but while executing taskService.start(), it gives this error:

15:55:58,398 WARN  [org.jbpm.services.task.persistence.TaskTransactionInterceptor] (http-localhost.localdomain/127.0.0.1:8080-2) Could not commit session: org.jbpm.services.task.exception.PermissionDeniedException: User 'null' does not have permissions to execution operation 'Start' on task id 2


Testing steps:

1) install BPMS 6.0.2 and add 2 users: [bpmsAdmin] and [root], add both of them with [admin] role.

2) package the mvn project 01135268 in the zip attachment, and make it a module for eap (`custom` folder is packaged already, just drop this into eap's module folder)

3) change business-central.war/WEB-INF/beans.xml as below to enable the custom usergroup call back

-------------------
<beans xmlns="http://java.sun.com/xml/ns/javaee";; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";;
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd">;;

  <alternatives>
<class>com.test.services.producer.CustomTestUserGroupInfoProducer</class>
  </alternatives>
  <interceptors>
    <class>org.uberfire.security.server.authz.cdi.RolesInterceptor</class>
    <class>org.uberfire.security.server.authz.cdi.TraitInterceptor</class>
  </interceptors>
</beans>
-------------------

4) add this dependency in business-central.war/WEB-INF/jboss-deployment-structure.xml:

<module name="custom.test.usergroupinfo" export="true" services="import" meta-inf="import"/>


5) start BPMS and login as bpmsAdmin, add a process def. include a simple user task, set the [Groups] to "admin" for this task (check rewards.bpmn2 file in zip)

6) start a process instance, and go to "Tasks - Task List", should be able to see it

7) Now, claim it with "bpmsAdmin" user, it is claimed correctly and others cannot see it in group list

But if use "root" user to claim it here, following log will be printed out and the task goes to "Reserved" status.


15:55:58,398 WARN  [org.jbpm.services.task.persistence.TaskTransactionInterceptor] (http-localhost.localdomain/127.0.0.1:8080-2) Could not commit session: org.jbpm.services.task.exception.PermissionDeniedException: User 'null' does not have permissions to execution operation 'Start' on task id 2
	at org.jbpm.services.task.internals.lifecycle.MVELLifeCycleManager.evalCommand(MVELLifeCycleManager.java:98) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.internals.lifecycle.MVELLifeCycleManager.taskOperation(MVELLifeCycleManager.java:322) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.identity.UserGroupLifeCycleManagerDecorator.taskOperation(UserGroupLifeCycleManagerDecorator.java:46) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.impl.TaskInstanceServiceImpl.start(TaskInstanceServiceImpl.java:204) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.StartTaskCommand.execute(StartTaskCommand.java:48) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.StartTaskCommand.execute(StartTaskCommand.java:30) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.CompositeCommand.execute(CompositeCommand.java:38) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.TaskCommandExecutorImpl$SelfExecutionCommandService.execute(TaskCommandExecutorImpl.java:65) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:41) [drools-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.persistence.TaskTransactionInterceptor.execute(TaskTransactionInterceptor.java:54) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.TaskCommandExecutorImpl.execute(TaskCommandExecutorImpl.java:40) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.impl.command.CommandBasedTaskService.start(CommandBasedTaskService.java:245) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.console.ng.ht.backend.server.TaskServiceEntryPointImpl.claimBatch(TaskServiceEntryPointImpl.java:512) [jbpm-console-ng-human-tasks-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.console.ng.ht.backend.server.TaskServiceEntryPointImpl$Proxy$_$$_WeldClientProxy.claimBatch(TaskServiceEntryPointImpl$Proxy$_$$_WeldClientProxy.java) [jbpm-console-ng-human-tasks-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
......





Actual results:

Task status is set to "Reserved" after failure.


Expected results:

If there is any error / exception during the executiion of TaskServiceEntryPointImpl#claimBatch(), the task status should rollback to the initial status (same as before we execute this method)


Additional info:

Comment 2 Mauricio Salatino 2014-12-10 18:53:34 UTC
For the composite actions such as start/claim now a Composite command is used that guarantees that both actions are executed in a single transaction. 
Here is the fix in 6.2.x: http://github.com/droolsjbpm/jbpm-console-ng/commit/e6831a81c

Comment 3 Jiri Svitak 2015-02-11 11:09:51 UTC
Created attachment 990417 [details]
reproducer-bpm-suite-6.1.0.ER4.zip

Comment 4 Jiri Svitak 2015-02-11 11:16:57 UTC
Verified in BPM Suite 6.1.0.ER4.

I have attached new reproducer for BPM Suite 6.1.0.ER4 (reproducer-bpm-suite-6.1.0.ER4.zip) as there were several changes necessary:

1.) module structure of jbpm services has changed in 6.1
2.) group 'admin' was changed to 'broker' and then I could see my testing task, because according to Mauricio, 'admin' tasks are filtered in 6.1:
(11:55:54 AM) salaboy: avoid using admin if you are not testing anything related with admin things
(11:56:29 AM) salaboy: well that could be because the task is being filtered to not show anythign related with admin groups or users
3.) jar containing UserGroupInfoProducer needs to be placed into business-central.war/WEB-INF/lib directory due to new fat war packaging, not into modules.

After that I could see the difference, in case of problematic 'root' user the task returned to 'Ready' status instead of wrong 'Reserved' one.

Comment 6 PnT Account Manager 2017-12-07 23:35:35 UTC
Employee 'msalatin@redhat.com' has left the company.


Note You need to log in before you can comment on or make changes to this bug.