Update last value when triggering nested flows with array values

[licitdev]

Description

Fixes #15653.

• $last updated to the correct payload for array values when triggering another flow
• keyedData in the child flow has a separate context from the parent flow

Type of Change

• Bugfix
• Improvement
• New Feature
• Refactor / codestyle updates
• Other, please describe:

Requirements Checklist

• New / updated tests are included
• All tests are passing locally
• Performed a self-review of the submitted code

If adding a new feature:

• Documentation was added/updated. PR:

[nickrum]

I'm wondering if it would be a good idea to fully isolate the sub-flow's data chain from the parent one except for the payload that is passed to $trigger (and that should be available in $last in the first operation after the trigger) by omitting it from context.
Flows triggered by other flows are kind of like sub-routines and $trigger is like a list of parameters. In that context, I think it makes sanse to isolate the scope of the parent from the child.

Regarding adding global shortcuts to $* values in the data chain to the exec operation, I'm not a huge fan of global variables, but I can see how this might be useful 👍

[licitdev]

isolate the scope of the parent from the child

@nickrum Agreed, users can define the payload, nesting values they require within.

However, I wonder if this scope limitation is considered a breaking change as the past behaviour of the $trigger variable is the $trigger from the parent context. If I understand correctly, the value of the $trigger and $last after scoping should be the payload triggering the "child" flow. Thoughts?

adding global shortcuts to $* values in the data chain to the exec operation

Just as a background, this was a suggestion in https://github.com/directus/docs/pull/185#issuecomment-1291147554 which I thought would be nifty and consistent within the flows data chain. 😄

[nickrum]

However, I wonder if this scope limitation is considered a breaking change as the past behaviour of the $trigger variable is the $trigger from the parent context. If I understand correctly, the value of the $trigger and $last after scoping should be the payload triggering the "child" flow.

Very good question! Yes, that's exactly how it was supposed to work. That's also how it is documented and how some users understood the feature (#14069). So, I think we should consider it a bug fix and add a notice in case some users relied on the broken behavior.

Just as a background, this was a suggestion in directus/docs#185 (comment) which I thought would be nifty and consistent within the flows data chain. 😄

Ohh, interesting! I thought @rijkvanzanten was suggesting to add the env vars as $env to the data chain, so all of the operations can access them instead of just the exec operation 🤔

[licitdev]

Yes, that's exactly how it was supposed to work.

Updated! Users have to define the payload to pass when triggering another flow.

all of the operations can access them instead of just the exec operation

Wow, this is a different interpretation! Was too focused on the run script operation, whereas this would make it truly consistent across the entire data chain. 😄 Thanks!

[licitdev]

@nickrum Just removed the global variables as they're hard to document and might get confusing. 😄