Define output of an async task (started with `await: false`)

[matthias-pichler]

What would you like to be added:

Something I missed in the PR #995 that introduced the await property is to define what the (raw) output of a task with await: false is.

We should document the output of a run task in general. Because what is the output of a run.container task?

Why is this needed:

Dicjment the output of an async task

[cdavernas]

As far as I understand it, an async task should output its transformed input. IMHO, runtimes should ignore output transformations and export, as async task should not be able to output.

As for "standard" run task output, it's a discussion we had in the past with @ricardozanini and @JBBianchi. If I remember well, it should be the task's stdout, but we should probably provide a flag that indicates whether or not to deserialize it, in case it's JSON or YAML encoded. We should probably open another issue to address that specific concern, which might also be related to #998

[matthias-pichler]

As for "standard" run task output, it's a discussion we had in the past with @ricardozanini and @JBBianchi. If I remember well, it should be the task's stdout, but we should probably provide a flag that indicates whether or not to deserialize it, in case it's JSON or YAML encoded. We should probably open another issue to address that specific concern, which might also be related to https://github.com/serverlessworkflow/specification/issues/998

I also thought about returning stdout, maybe it might even be worth it to return an object

{
  "stdout": "...",
  "stderr":  "..."
}

since some tools print a lot to stderr as well and it might be needed to detect errors. But in other cases some containers might be very noise and so authors might want to discard the output. Maybe the way to go is an output property similar to call: http?

document: {}
do:
  - runContainer:
      run:
        container:
          image: alpine:latest
          output: "stdout" # "stdout" | "stderr" | "all" | "none"

I am unsure if we should handle JSON/YAML deserialization since jq offers @json @html, ... see jq manual

Do we have to introduce the same thing for run.shell?

[cdavernas]

@matthias-pichler Great idea! And yes, I would extend your proposal to all processes, not just shell!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.