specify jq expression $input variable

[matthias-pichler]

What would you like to be added:

In some runtime expressions the jq variable/arg $input is used.

Examples:

https://github.com/serverlessworkflow/specification/blob/2d79abeff483a4933f459a576e86436df5b87a4b/ctk/features/data-flow.feature#L84-L85

https://github.com/serverlessworkflow/specification/blob/2d79abeff483a4933f459a576e86436df5b87a4b/dsl-reference.md?plain=1#L176-L177

Both these examples include the use in the output section. This raises the question: Is the $input variable only available in expression in the output section? This wouldn't make sense to me because one might want to extend the input in the input section as well:

input:
  from: $input + { foo: "bar" }

For the output section it is not mentioned whether the $input variable refers to the input before or after the input.from expression is applied. I assume after?

Why is this needed:

For an implementation it is relevant to know which variables to pass to the jq runtime

[cdavernas]

All arguments are available at all time by default.

You could argue, however, like we did a lot in the past, that $context should only be passed during input and output filtering, for scoping sakes (ex: invoking a FaaS to which you don't want to pass all the available data, "just" the filtered input). We still need to make a final decision about it, you're welcome to jump in.

For more information about arguments that should be passed to expresions, see https://github.com/serverlessworkflow/specification/blob/main/dsl.md#runtime-expression-arguments.

You are more than welcome to contribute, if you'd like, to the parts that you feel are unclear or lacking!

[matthias-pichler]

Thanks! My bad, I somehow missed that section. That makes sense to me.

Yeah the scoping might make sense to avoid these kinds of size restrictions. I personally would prefer $context only existing in the input and output expressions so that tasks would really only get the input.

But I don't think this issue is the right place for this discussion, so closing now. But feel free to reopen if you want.

[cdavernas]

Thanks! My bad, I somehow missed that section. That makes sense to me.

@matthias-pichler-warrify No worries, you are most welcome! The doc is a first raw attempt, and is both unclear and lacking on many aspects.

I personally would prefer $context only existing in the input and output expressions so that tasks would really only get the input.

Me too! It's IMO clearly the way to go to enforce encapsulation, to avoid bleeding sensitive data and to further increase atomicity.