Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-14032

Interrupting Conditional Boundery Event not firing

    • Icon: Bug Report Bug Report
    • Resolution: Cannot Reproduce
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • engine
    • None

      Environment (Required on creation):

      Camunda Run 7.16.0-ee

      Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

      When i created a process which has a conditional boundary event on a user task, even when the condition is met - the boundary event does not fire.

      Not matter if the condition is present when the task is reached or the condition happens after the task is reached.

      Steps to reproduce (Required on creation):

      Deploy the process uploaded (along with the form if you're feeling fancy)

      Start the process from task list and add a variable called "stop" as a boolean set to true. (this is the condition on the event)

      Click Start.

      Observed Behavior (Required on creation):

      The task appears in tasklist

      Expected behavior (Required on creation):

      The task should have been canceled by the event and should have interrupted.

      Root Cause (Required on prioritization):

      Solution Ideas (Optional):

      Hints (optional):

      I tested this on 7.15.0-ee and it worked as expected.

       

        This is the controller panel for Smart Panels app

            [CAM-14032] Interrupting Conditional Boundery Event not firing

            Hey niall.deehan,

            thanks for bringing this up and providing all the necessary details already!
            We'll try to reproduce and root cause this as soon as possible.

            Thanks and stay tuned,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hey niall.deehan , thanks for bringing this up and providing all the necessary details already! We'll try to reproduce and root cause this as soon as possible. Thanks and stay tuned, Tobias

            Hey niall.deehan,

            I gave it a try and have to say I cannot reproduce that behavior.

            • I used Run 7.16.0-ee and added your files as resources - all worked as expected with the variable being present at the start and with adding it when the task has been created already. The conditional event just kicks in as expected.
            • I also tried it with the https://github.com/camunda/camunda-engine-unittest, adding your resources and the following test cases - both are green on my machine.
                @Test
                @Deployment(resources = {"BoundaryEventProcess.bpmn", "NiceLittleForm.form"})
                public void shouldFireConditionOnExistingTask() {
                  // Given we create a new process instance
                  ProcessInstance processInstance = runtimeService().startProcessInstanceByKey("BookProcess");
                  // Then it should be active
                  assertThat(processInstance).isActive();
                  // And it should be the only instance
                  assertThat(processInstanceQuery().count()).isEqualTo(1);
                  // And there should exist just a single task within that process instance
                  assertThat(task(processInstance)).isNotNull();
              
                  // When we set the variable
                  runtimeService().setVariable(processInstance.getId(), "stop", true);
                  // Then the process instance should be ended
                  assertThat(processInstance).isEnded();
                }
                
                @Test
                @Deployment(resources = {"BoundaryEventProcess.bpmn", "NiceLittleForm.form"})
                public void shouldFireConditionWithExistingVariable() {
                  // Given we create a new process instance with the condition variable
                  ProcessInstance processInstance = runtimeService().startProcessInstanceByKey(
                      "BookProcess", 
                      Variables.createVariables().putValue("stop", true)
                  );
              
                  // Then the process instance should be ended
                  assertThat(processInstance).isEnded();
                }
              

            Let me know if I missed something when trying to reproduce this.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hey niall.deehan , I gave it a try and have to say I cannot reproduce that behavior. I used Run 7.16.0-ee and added your files as resources - all worked as expected with the variable being present at the start and with adding it when the task has been created already. The conditional event just kicks in as expected. I also tried it with the https://github.com/camunda/camunda-engine-unittest , adding your resources and the following test cases - both are green on my machine. @Test @Deployment(resources = { "BoundaryEventProcess.bpmn" , "NiceLittleForm.form" }) public void shouldFireConditionOnExistingTask() { // Given we create a new process instance ProcessInstance processInstance = runtimeService().startProcessInstanceByKey( "BookProcess" ); // Then it should be active assertThat(processInstance).isActive(); // And it should be the only instance assertThat(processInstanceQuery().count()).isEqualTo(1); // And there should exist just a single task within that process instance assertThat(task(processInstance)).isNotNull(); // When we set the variable runtimeService().setVariable(processInstance.getId(), "stop" , true ); // Then the process instance should be ended assertThat(processInstance).isEnded(); } @Test @Deployment(resources = { "BoundaryEventProcess.bpmn" , "NiceLittleForm.form" }) public void shouldFireConditionWithExistingVariable() { // Given we create a new process instance with the condition variable ProcessInstance processInstance = runtimeService().startProcessInstanceByKey( "BookProcess" , Variables.createVariables().putValue( "stop" , true ) ); // Then the process instance should be ended assertThat(processInstance).isEnded(); } Let me know if I missed something when trying to reproduce this. Best, Tobias

            Closing this due to inactivity.
            If you can reproduce this again, feel free to reopen.
            We can then try to identify why this doesn't fail in my setups.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Closing this due to inactivity. If you can reproduce this again, feel free to reopen. We can then try to identify why this doesn't fail in my setups. Best, Tobias

              Unassigned Unassigned
              niall.deehan Niall Deehan
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: