Add support for registering custom tasks

[hughneale]

What this PR does / why we need it:

As per the serverlesss workflow spec aside from the default tasks. Users should be able to register their own tasks for their own serverless workflow implementations

Special notes for reviewers:

Additional information (if needed):

[ricardozanini]

@hughneale thanks! Can you take a look at the CI error? The code looks ok, can you add a link to the spec to this PR, or open an issue with a link to it? So we have it documented and traced back to the spec. Thanks!!

[hughneale]

@ricardozanini good to merge? Thanks for the review.

[ricardozanini]

@hughneale I'm curious about where in the spec we have custom tasks specified. I haven't found this info there.

[hughneale]

@ricardozanini - The spec says:

Tasks are designed to be modular and focused, each serving a distinct purpose within the broader context of the workflow.

By breaking down the workflow into manageable tasks, organizations can effectively coordinate and track progress, enabling efficient collaboration and ensuring that work is completed in a structured and organized manner.

The Serverless Workflow DSL defines a list of tasks that must be supported by all runtimes:

For me reading this. It says that tasks are modular and the list below are the tasks that at a minimum need to be implemented. It doesn't say that these are the only tasks that can be supported. So as it's designed to be modular I'd reasoned that support for registering custom tasks was acceptable.

[cdavernas]

@hughneale While your interpretation makes a lot of sense, I believe it’s essential to emphasize the portable nature of workflows defined in Serverless Workflow. Consequently, custom implementations should generally be avoided in favor of extensions and custom functions, which are constructed using the fundamental building blocks defined by the specification — and are therefore fully portable across runtimes.

See https://github.com/serverlessworkflow/specification/blob/main/dsl.md#extensions
And https://github.com/serverlessworkflow/specification/blob/main/dsl.md#custom-and-non-standard-interactions

[ricardozanini]

Exactly, "custom" tasks are extensions that are pre-defined tasks using the very same block of executions already defined in the specification.

[hughneale]

Thanks guys. The problem I am running into is I want to be able to provide simplified components (which maybe a collection of tasks) for people to use. For example I want to provide a task that:

• Takes an input (star wars character)
• to a call.http: to lookup the character info
• for: Loops over all the places they've been
• call.http again + export/output as to get the data into a workable state
• etc etc

This could of course be a sub workflow. However, there's a lot of work to do to put this together and I would rather provide a custom task like:

do:
    starwars: getCharacterLocations
    with:
        name: Luke Skywalker

I don't want to inject workflow tasks or modify workflows created as this can obviously create its own issues.

You could argue that I could just create a custom function to do all of this. However, I want to make each function directly callable so it can be individually retried and faulted. Rather than the entire function that may encapsulate 10 calls and then it becomes more problematic to recover from and revert state if needed.

My real world example is here: https://github.com/thand-io/agent/blob/main/internal/workflows/tasks/providers/thand/approvals.go#L61 that mixes listening, switches, export etc that I just don’t want a user building a workflow to have to deal with.

I hope that helps.