Try task generates wrong jsonPosition for the nested catch task

[wmedvede]

While executing the attached process try-catch-with-retry-and-do the following behaviour was observed.

The tryTask gets the following position: do/0/tryTask/try which is correct

The faillngTask gets the follwoing jsonPositon: do/0/tryTask/try/0/failingTask (see that it's preceeded with the parent position do/0/tryTask/try) which is correct.

However, the executeAfterFailingTask gets the following jsonPosition: do/0/tryTask/catch/do/0/executeAfterFailingTask .

See that there's no way to relate it with the parent.

Since the task is derived from the tryTask execution, it must get a jsonPositon like this: do/0/tryTask/try/catch/do/0/executeAfterFailingTask

test-try-catch-wity-retry-and-do.yaml

[fjtirado]

The parent task of the catch is tryTask, not tryTask/try. Thats intentional. In my opinion (and @gmunozfe if I recall correclty) the current position is the right one.

In other words, Both tryTask/try and tryTask/catch has the same parent, tryTask. If catch was a child of try it would be indented on the definition file, which is not the case. The criteria for position follows the spec and the indentation on the definition files, as it can be seen in the attached yaml file

- tryTask:
      try:
        - failingTask:
            raise:
              error:
                type: https://example.com/errors/runtime
                status: 500
      catch:
        errors:

[gmunozfe]

I agree with the @fjtirado's comment:
It should not include /try/catch, because catch is not nested inside try. So, this issue is not correct from my point of view.

[wmedvede]

For me, from the jsonPath point of view, a task, should have one entry point/path, and from there, you shoud have "access" to all the semantic that implements the task.
Two paths like below, at least for me, give the idea of something that is "split".

do/0/tryTask/try/0/failingTask

do/0/tryTask/catch/do/0/executeAfterFailingTask

[fjtirado]

The identifier of the task is do/0/tryTask
Within try you have the operations (the list of task, which have try in the json path) that are normally executed.
If there is an exception, then there is a "split" in the regular execution path and the catch block is executed. The catch is not under the try, it is at the same level, therefore, tasks executed as part of the catch do not have the try keyword in the jsonpath, but they share the same parent task path than the try.