This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 818251 - JPA knowledge session does not set process instance as completed after user task completion
JPA knowledge session does not set process instance as completed after user t...
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Maciej Swiderski
Radovan Synek
Depends On:
  Show dependency treegraph
Reported: 2012-05-02 11:09 EDT by Radovan Synek
Modified: 2013-08-20 10:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Radovan Synek 2012-05-02 11:09:31 EDT
Process instance stays in "active" state after user task has been completed (simple process start -> user task -> end). This happens only with JPA knowledge session; with common stateful knowledge session without persistence process instance is marked as "completed".

On the other hand ProcessCompletedEvent is fired in both cases.

The reproducer will be added soon.
Comment 1 Radovan Synek 2012-05-02 11:22:14 EDT
here is the promised reproducer:
Comment 2 Maciej Swiderski 2012-05-03 05:42:06 EDT
Tests fails due to inspecting disconnected snapshot of the process instance since it uses persistence after completion the process instance does not reflect the latest status. Instead of verifying of the disconnected status you should use helper assertion methods that come with JbpmBpmn2TestCase, for instance to check if instance is completed:
assertProcessInstanceCompleted(pi.getId(), ksession);

instead of 
assertEquals(ProcessInstance.STATE_COMPLETED, pi.getState());

more details about test support can be found in documentation:
Comment 3 Radovan Synek 2012-05-04 04:01:27 EDT
Hi Maciej,

actually I don't use these assertions, because ProcessInstance class has defined 5 different states and there are only 3 assert methods: completed, aborted, active. Moreover, assertProcessInstanceCompleted and assertProcessInstanceAborted both check if process instance is null => you can't distinguish between completed and aborted process instance. AssertProcessInstanceActive checks if the process instance is not null. Again, no state checking.

If you take a look on JBPM unit tests - especially BPMN2 module, you can see there are used both ways - assertProcessInstanceCompleted and checking ProcessInstance.STATE_COMPLETED.

But as far as I understand it, none of them can be used safely.


Comment 4 Maciej Swiderski 2012-05-04 05:38:34 EDT
Radek, I got your point and in fact I agree with it that we could think about improved version of tests assertion to not make user confused with the results and I believe that was the intention of having this helper methods to shield users from checking it differently if it uses persistence or not. Session will have only processes that are active and thus you get null for completed processes. Additionally you could verify completed nodes with another helper method to secure they were visited as expected (assertNodeTriggered).

I believe the issue reported by this bz could be considered as work as design since the process is completed as expected. Whyt?
Comment 5 Kris Verlaenen 2012-05-09 12:28:33 EDT
The reported issue is not a bug, as everything is working as expected.  I agree that we can improve the assertions, and depending on what features you have enabled (persistence, audit log, etc.) we can then make the assertions more intelligent.

We will take these recommendations into account.  Adding dev_ack- for now, as there's no time to do these improvements for this release unfortunately.
Comment 6 Maciej Swiderski 2013-08-20 10:30:04 EDT
assertions has been improved as can be seen here:

Shall this bz be moved to version 6 somehow? If so I would mark it as verified.

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