Closed matthias-pichler closed 3 months ago
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!
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.
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.
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 theoutput
section? This wouldn't make sense to me because one might want to extend the input in theinput
section as well:For the
output
section it is not mentioned whether the$input
variable refers to the input before or after theinput.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