Steps to reproduce
- A process has two tasks "foo" and "bar"
- Task "foo" is asyncBefore
- The execution of task "bar" fails
- 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
- The id of the problem causing activity is additionally stored in:
- the failed job log
- the runtime job
- the runtime incident
- the historic incident
- The new id is exposed via REST API for those entities as well.
Related blog post https://forum.camunda.org/t/showing-which-step-really-failed/13051