Uploaded image for project: 'Red Hat Process Automation Manager'
  1. Red Hat Process Automation Manager
  2. RHPAM-3261

[GSS] (7.8.x) Nested process instances abort doesn't work when a task in event subprocess is marked with "Is Async" as "true"

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.9.1.GA
    • 7.8.0.GA
    • jBPM Core

    • RHPAM 7.8.0

    • False
    • False
    • CR1
    • +
    • Undefined
    • Hide

      1. Import the attached reproducer into BC and deploy to kie-server (cascade_abort.zip).

      • Unzip "cascade_abort.zip" attachment
      • Import the reproducer into the BC
      • Deploy to kie-server
        2. Start a process instance for the process "cascade-abort.Parent"
        3. You'll notice that the status of "Child" will be "Aborted" but "Parent" will be "Completed" and this is not expected. The "Parent" process should also move to aborted state.
        4. Now, change the value of "Is Async" to false in the processes as follows.
        a.) Open the process "cascade-abort.HandleException" and set 'Is Async" to false for the tasks - init, rest-api1, rest-api2 and save it.
        b.) Open the process "cascade-abort.Parent" and inside the Event Sub-process, set "Is Async" to false for the sub-process "exception-handler" and save it.
        5. Deploy the project and start a process instance for the process "cascade-abort.Parent"
        6. You'll notice that the status of both "Child" and "Parent" will be "Aborted" as expected.

      So, marking the tasks in the event-sub-process with "Is Async" to true is producing an unexpected state change to the parent processes.

      The expected behavior is that both "Parent" and "Child" process instances should move to "Aborted' state irrespective of whether it has safe-points (Is Async to true) enabled or not.

      Show
      1. Import the attached reproducer into BC and deploy to kie-server (cascade_abort.zip). Unzip "cascade_abort.zip" attachment Import the reproducer into the BC Deploy to kie-server 2. Start a process instance for the process "cascade-abort.Parent" 3. You'll notice that the status of "Child" will be "Aborted" but "Parent" will be "Completed" and this is not expected. The "Parent" process should also move to aborted state. 4. Now, change the value of "Is Async" to false in the processes as follows. a.) Open the process "cascade-abort.HandleException" and set 'Is Async" to false for the tasks - init, rest-api1, rest-api2 and save it. b.) Open the process "cascade-abort.Parent" and inside the Event Sub-process, set "Is Async" to false for the sub-process "exception-handler" and save it. 5. Deploy the project and start a process instance for the process "cascade-abort.Parent" 6. You'll notice that the status of both "Child" and "Parent" will be "Aborted" as expected. So, marking the tasks in the event-sub-process with "Is Async" to true is producing an unexpected state change to the parent processes. The expected behavior is that both "Parent" and "Child" process instances should move to "Aborted' state irrespective of whether it has safe-points (Is Async to true) enabled or not.
    • ---
    • ---
    • 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30)

      I just uploaded another reproducer which contains more examples to reproduce the issues. I've installed the 7.9.0.CR2 and imported the "cascade_abort_2.zip" reproducer attached to this JIRA. As Bala told us before, the first issue described in the "Steps to Reproduce" section of this JIRA works as intended for the processes "Parent", "Child" and "HandleException" in 7.9.0.CR2. However the following cases are still failing:

      Case 1:

      1. Import the "cascade_abort_2.zip" reproducer into the BC
      2. Deploy to kie-server
      3. Start a process instance for the process "nested-abort.level1P"
      4. This will create three process instances level1P --> level2C --> level3SC and all 3 of them will move to "Completed" state which is incorrect.
      5. Now, change the value of "Is Async" to false in the processes as follows.
      a.) Open the process "nested-abort.exception" and set 'Is Async" to false for the tasks - Init, REST and save it.
      b.) Open the process "nested-abort.level3SC" and inside the Event Sub-process, set "Is Async" to false for the sub-process "exception-process" and save it.
      6. Deploy the project and start a process instance for the process "nested-abort.level1P"
      7. You'll notice that the status of all three process instances - level1P --> level2C --> level3SC will be "Aborted" as expected.

      Case 2:

      1. Import the "cascade_abort_2.zip" attached reproducer into the BC
      2. Deploy to kie-server
      3. Start a process instance for the process "nested-abort.MainProcess"
      4. This will create 2 process instances MainProcess --> SubProcess and both of them will move to "Aborted" state as expected.
      5. However, if you look at the server.log, you'll notice the lots of warnings like [1]. Also, if you see the process instance diagram, the event sub-process in the "MainProcess" wouldn't have got completed and the execution would have got stuck before the task "log-error".
      6. Now, change the value of "Is Async" to false as follows.
      a.) Open the process "nested-abort.MainProcess" and set "Is Async" to false for the task "log-error" in the event sub-process and save it.
      7. Deploy the project and start a process instance for the process "nested-abort.Mainprocess"
      8. You'll notice that the status of both the process instances - MainProcess --> SubProcess will be "Aborted" as expected and also, the event sub-process in the "MainProcess" would have got completed successfully.

      I could reproduce the cases above in 7.9.0.CR2. Could you take a look, please?

      Regards,
      Oscar

        1. cascade_abort_2.zip
          221 kB
        2. cascade_abort.zip
          169 kB

              elguardian@gmail.com Enrique González Martínez (Inactive)
              rhn-support-omolinab Oscar Molina
              Gonzalo Muñoz Fernández Gonzalo Muñoz Fernández
              Gonzalo Muñoz Fernández Gonzalo Muñoz Fernández
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: