Catch Block Not Considering Updated Context in Switch Execution

[sonathaj]

I tried this:

I created a workflow where tasks are executed sequentially from a list (tasks). After each task executes, it is removed from the list using del(.tasks[0]), ensuring that only the remaining tasks proceed.

If a task fails, the catch block should log the failed task and remove it from the list before proceeding.

(Basically I need to execute multiple blocks within a single try and catch instead of using a try and catch each for each block)

Below is the sample workflow I created to test this scenario:

document:
  dsl: 1.0.0-alpha5
  namespace: default
  name: try-catch-context-test
  version: 0.1.1
do:
- dummyTaskSetForTry:
    do:
    - setTasksList:
        set:
          failedTasks: []
          tasks:
          - dummyTask1
          - dummyTask2
          - dummyTask3
          - dummyTask4
        export:
          as: $context + .
    - switchBlock:
        switch:
        - decisionMaker:
            when: ${ ($context.tasks != null) and ($context.tasks | length )  > 0 }
            then: executeTasks
        - default:
            then: exitSwitch
    - executeTasks:
        try:
        - determineTask:
            switch:
            - jumpToTask1:
                when: ${ $context.tasks != null and ($context.tasks | map(. == "dummyTask1") | any) }
                then: task1
            - jumpToTask2:
                when: ${ $context.tasks != null and ($context.tasks | map(. == "dummyTask2") | any) }
                then: task2
            - jumpToTask3:
                when: ${ $context.tasks != null and ($context.tasks | map(. == "dummyTask3") | any) }
                then: task3
            - jumpToTask4:
                when: ${ $context.tasks != null and ($context.tasks | map(. == "dummyTask4") | any) }
                then: task4
        - task1:
            set:
              dummySet1: dummySet1
            export:
              as: $context | del(.tasks[0])
        - remListAftertask1:
            set:
              remListAftertask1: ${  $context.tasks }
            export:
              as: $context + .
        - task2:
            set:
              dummySet2: dummySet2
            export:
              as: $context | del(.tasks[0])
        - remListAftertask2:
            set:
              remListAftertask2: ${  $context.tasks }
            export:
              as: $context + .
        - task3:
            call: set-widget-state:5.0.0@default  # no such version exists, added here to hit the catch block
            with:
              id: test-id
              state:
                values: test-values
            export:
              as: $context | del(.tasks[0])
        - remListAftertask3:
            set:
              remListAftertask3: ${  $context.tasks }
            export:
              as: $context + .
        - task4:
            set:
              dummySet4: dummySet4
            export:
              as: $context | del(.tasks[0])
        - remListAftertask4:
            set:
              remListAftertask4: ${  $context.tasks }
            export:
              as: $context + .
        catch:
          do:
          - setErrorFlag:
              set:
                catchBlock: ${ $context.tasks[0] }
                failedBuildTasks: ${ $context.failedTasks + [$context.tasks[0]] }
              export:
                as: $context | del(.tasks[0])
    - goToMainSwitchBlock:
        set:
          listAfterCatch: ${ $context.tasks }
          dummy: true
        export:
          as: $context + .
        then: switchBlock
    - exitSwitch:
        set:
          dummy: true

This happened:

• The first two tasks (dummyTask1 and dummyTask2) executed correctly, and each was successfully removed from tasks.

• When dummyTask3 failed, the catch block executed.

• Instead of removing dummyTask3 (the failed task), dummyTask1 (which had already been removed) was removed again.

• This suggests that the catch block is not considering the updated context from the switch execution and is instead using an outdated state.

I expected this:

• The catch block should remove the task that failed (dummyTask3 in this case).

• It should respect the most recent updates to the context (tasks) before handling errors.

Is there a workaround?

No response

Anything else?

No response

Platform(s)

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.name: Bug Report 🐞

[cdavernas]

@sonathaj I tried a much simpler flow to check if the context was properly updated in the catch clause, and it works as expected. The problem must reside somewhere else in your flow.

document:
  dsl: 1.0.0-alpha5
  namespace: default
  name: new-workflow
  version: 0.1.0
do:
- tryCatch:
    try:
    - throw:
        call: set-widget-state:5.0.0@default
        with:
          id: test-id
          state:
            values: test-values
        export:
          as: $context | del(.tasks[0])
    catch:
      do:
      - setFooBar:
          set:
            foo: bar
          export:
            as: '{ foo: "barbaz" }'

Context after execution:

foo: barbaz

[sonathaj]

Hi @cdavernas,

Thank you for looking into this! I agree that the isolated try-catch example works as expected, but the issue seems to surface specifically during iteration over a dynamic task list using the switch construct.

Repro Scenario
In my workflow, I:

1. Iterate through tasks using switch to route execution.

2. Remove completed tasks via export: as: $context | del(.tasks[0]).

3. Expected Behavior: On task failure (e.g., dummyTask3), the catch block should remove the failed task (dummyTask3).

4. Actual Behavior: The catch block removes dummyTask1 (already processed), suggesting the context snapshot used in catch doesn’t reflect prior updates.

Request

Could you test with my full iterative example? The minimal case misses the interaction between:

• Dynamic list modification (del(.tasks[0]),

• switch-based iteration, and

• catch block context resolution.

It would be great to confirm if this is a bug or intended behavior.

Thanks again for your time!