[Fix #1148] Add then flow directive to catch clause

[ricardozanini]

Summary

• Add then property (type flowDirective) to the catch clause of try tasks
• Enables control flow transitions after catching errors (e.g., then: handleError to jump to a shared error-handling task)
• Avoids duplicating inline do blocks when multiple try tasks need the same error-handling sequence

Changes

• schema/workflow.yaml: Added then property referencing flowDirective to TryTaskCatch
• dsl-reference.md: Added then row to the Catch properties table
• examples/try-catch-then-directive.yaml: New example demonstrating the then directive in a catch clause

Test plan

• All 130 validation tests pass (including the new example)

Fixes #1148

[Copilot]

Pull request overview

Adds support for a then flow directive in the catch clause of try tasks in the Serverless Workflow DSL, enabling workflows to transition to a shared error-handling task after an error is caught.

Changes:

• Extended the workflow schema to allow catch.then (as a flowDirective) on try tasks.
• Updated the DSL reference to document the new then property for catch.
• Added a new example workflow demonstrating catch.then.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
schema/workflow.yaml	Adds then to TryTaskCatch, referencing the shared flowDirective definition.
dsl-reference.md	Documents the new catch.then property in the Catch properties table.
examples/try-catch-then-directive.yaml	Adds an example showing then used in a catch clause.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[ricardozanini]

@cdavernas can you have another look please?

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

dsl-reference.md:1258

• The ordering/precedence between catch.do and catch.then is still ambiguous for readers: if tasks inside catch.do include their own explicit flow directives (then, end, etc.), it’s unclear whether catch.then is ignored, enforced after do, or invalid. Consider documenting the exact precedence rules (and any invalid combinations) here and/or in the schema description so authors know which transition wins.

| then | [`flowDirective`](#flow-directive) | `no` | The [flow directive](#flow-directive) to execute for the error path after the error has been caught (and after executing any `do` tasks, if set). This determines the next transition for the catch path (overriding the try task’s normal completion flow). |

dsl-reference.md:1258

• The text uses a typographic apostrophe (’), which can be inconsistent with repos that prefer plain ASCII and can make searching/copy-paste harder. Consider changing try task’s to try task's for consistency.

| then | [`flowDirective`](#flow-directive) | `no` | The [flow directive](#flow-directive) to execute for the error path after the error has been caught (and after executing any `do` tasks, if set). This determines the next transition for the catch path (overriding the try task’s normal completion flow). |

examples/try-catch-then-directive.yaml:26

• The example’s error target task (recordFailure) doesn’t explicitly terminate or transition. If the DSL allows implicit end-of-list completion this may still work, but it’s less clear for readers and inconsistent with continueProcessing which explicitly then: end. Consider adding an explicit terminal transition (e.g., then: end) so the example unambiguously demonstrates the intended control flow on the catch path.

  - recordFailure:
      set:
        status: failed

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

schema/workflow.yaml:1060

• The description implies catch.then runs after executing catch.do, but it doesn’t clarify what happens if tasks within catch.do perform their own flow transitions (e.g., an inner task uses then, end, etc.). This can make the precedence ambiguous for users. Consider explicitly documenting the precedence/behavior (e.g., whether catch.then only applies when the catch.do task list completes via default sequential flow, and whether explicit transitions inside catch.do bypass catch.then).

            then:
              $ref: '#/$defs/flowDirective'
              title: TryTaskCatchThen
              description: The flow directive to execute for the error path after the error has been caught (and after executing any `do` tasks, if set). When set, this determines the next transition instead of the try task's top-level `then` or the default sequential flow.

dsl-reference.md:1258

• This text also has the same precedence ambiguity as the schema description regarding interactions between catch.do task-level transitions and catch.then. Recommend adding a short clarifying sentence about how catch.then behaves when catch.do is present and contains tasks that explicitly redirect control flow.

| then | [`flowDirective`](#flow-directive) | `no` | The [flow directive](#flow-directive) to execute for the error path after the error has been caught (and after executing any `do` tasks, if set). This determines the next transition for the catch path (overriding the try task’s normal completion flow). |