Charles d'Avernas

> On another note: I think we could also utilize use.containers to build a container @matthias-pichler Thank you for the suggestion, but I have some concerns about the idea, mainly...

@JBBianchi I agree with you, but on the other hand leaving them accessible everywhere is like telling the authors it's ok to use them everywhere, like when calling a (potentially...

> @JBBianchi good point. It's much harder to accidentally leak the $secrets arg than the input I disagree. I don't see why it would be harder. For most users, `$secrets`...

To quote ChatGPT's opinion on it: In a Serverless Workflow, the availability of the `$secrets` argument should be carefully considered to balance security and flexibility. ### 1. Security Considerations -...

@matthias-pichler very good sample, which perfectly demonstrates your rightful concerns. You could however leak them in a similar fashion using the runtime expression argument. Anyways, I won't endlessly ramble on...

> Imagine a distributed runtime where each activity processor is a FaaS for instance. Very good point, which was also, if I remember properly, part of the motivation of the...

> Does it fall through to the next task? That is my understanding, yes: it should fall back to the `then` defined by the switch task, which actually defaults to...

> The "feature" resides in when, not in the name of the case I disagree. Naming cases is critical for (non author) user feedback and for cosmetic purpose: you do...

@ricardozanini @fjtirado @matthias-pichler-warrify What do you guys think? I think we need your input to determine whether or not we should proceed with potential changes. A good tiebreaker, if need...

@fjtirado I'm not sure I understand your sample: a matching case will transition, therefore won't ever fire the then, which will only be matched if nor increaseSalary or fireEmployee match....