unum-cli: command not found
How can I use this system？

$0: my index
$1: my parent's index (the first OuterLoop)

Full Step Functions Choices support.

Cases where function should pass UnumMetadata forward:

• Map and Parallel whose iterations consist of multiple functions. Only the last function performs fan-in. All other functions should pass UnumMetadata forward.
• A fan-out node followed by another fan-out node (tree). Each level should fan-in to the correct data store.

Do not execute the user function at all when a non-entry function is triggered first.

This scenario can happen when:
Ill-defined workflow: a workflow is deploy with Start: True in none of its unum-config.json and therefore no entry function from the unum runtime's perspective.
Client directly invoke a non-entry function in a well-defined workflow.

Either way, the runtime should check if the input payload already has a Session field or that the function's unum-config.json has Start: True.

Mark the start function in the unum config. The start function needs to create a context in the intermediary data store for each invocation of the workflow.

Having each fan-out initiator create a separate context causes problems for nested fan-outs. It is also unnecessary when the function outputs have unique names that can always identify the writer, particularly in the case of parallel and map fan-outs.

Raising exceptions when the unum runtime encounters an error causes Lambda to retry the function. However, the retry is doomed to fail again and therefore pointless. Instead, unum should record runtime errors in the unum data store.

For example, on s3, write runtime errors in session_context/errors/.

Entry function validation

If programmers write unum IR directly, they need to make sure that the unum-template.yaml has Start: true under one of the functions. They can optionally add Start: True into the same function's unum-config.json, but it's not required. unum-cli build will use the unum-template.yaml file to add a Start: True to the entry function's unum-config.json if that's not already present. unum-cli build also validates that only one of the functions of the workflow has Start: True in its unum-config.json. If the programmer added Start: True to multiple functions, either directly or through unum-template.yaml, unum-cli build will fail.

Use unum-template.yaml to add Start: True if Start: true exists in unum-template.yaml
Go through all functions to make sure there's one and only one function whose unum-config.json has Start: True.

The default behavior is if entry function, run it and run the rest of the workflow; if non-entry function, fail immediately.

Add a control field in the input payload that change the behavior:

1. Run this function by itself without triggering the rest of the workflow
2. Run this function and the rest of the workflow

Adding this feature can enable the following capabilities:

1. Run entry function alone without triggering the rest of the workflow
2. Run a non-entry function alone without triggering the rest of the workflow
3. Start with a non-entry function and run the rest of the workflow

The unum runtime and backend compiler should support more than just one backend platform. It will help to demonstrate the following:

1. The interoperability (platform-independent) of the unum IR and what we gain with the frontend compiler step.
2. Extensibility. The advantage of relying on simple primitives, namely any environment that has a FaaS system and a form of shared indexed storage. This point can be further strengthened if we show that adding a backend isn't much work.

We should aim to have another managed cloud platform (azure) and an on-premise platform (openfaas) to show that unum works under different environments.