We couldn't load the project sidebar. Refresh the page to try again.
If the problem persists, contact your Jira admin.
Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-10378

Accurately show the failed activity in cockpit

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.13.0, 7.13.0-alpha1
    • None
    • None
    • None

      Steps to reproduce

      1. A process has two tasks "foo" and "bar"
      2. Task "foo" is asyncBefore
      3. The execution of task "bar" fails

      Problem

      • As a result, the process transaction is rolled back but there is no information stored in which activity exactly the problem occurred
      • The failed job log only contains the first activity id executed as part of the failed process transaction

      Solution

      1. The id of the problem causing activity is additionally stored in:
        • the failed job log
        • the runtime job
        • the runtime incident
        • the historic incident
      2. The new id is exposed via REST API for those entities as well.

      Hints
      Related blog post https://forum.camunda.org/t/showing-which-step-really-failed/13051

        This is the controller panel for Smart Panels app

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

            Accurately show the failed activity in cockpit

            XMLWordPrintable

              • Icon: Feature Request Feature Request
              • Resolution: Fixed
              • Icon: L3 - Default L3 - Default
              • 7.13.0, 7.13.0-alpha1
              • None
              • None
              • None

                Steps to reproduce

                1. A process has two tasks "foo" and "bar"
                2. Task "foo" is asyncBefore
                3. The execution of task "bar" fails

                Problem

                • As a result, the process transaction is rolled back but there is no information stored in which activity exactly the problem occurred
                • The failed job log only contains the first activity id executed as part of the failed process transaction

                Solution

                1. The id of the problem causing activity is additionally stored in:
                  • the failed job log
                  • the runtime job
                  • the runtime incident
                  • the historic incident
                2. The new id is exposed via REST API for those entities as well.

                Hints
                Related blog post https://forum.camunda.org/t/showing-which-step-really-failed/13051

                  This is the controller panel for Smart Panels app

                        nikola.koevski Nikola Koevski
                        fml2 fml2
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        5 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                              nikola.koevski Nikola Koevski
                              fml2 fml2
                              Votes:
                              0 Vote for this issue
                              Watchers:
                              5 Start watching this issue

                                Created:
                                Updated:
                                Resolved: