Add multiple "to"s in transitions

[HamzaFarhan]

I noticed that the "from" in a transition can be a list of strings. So multiple actions can go to the same action if a certain condition is met:
(["action_a", "action_b"], "action_c", CONDITION)
What about going from one action to multiple actions if a condition is met?
("action_a", ["action_b", "action_c"], CONDITION)
Would updating the with_transitions function in GraphBuilder be enough?
Or would this lead to some sequencing issues? Or maybe it's our responsibility as devs to not go to multiple actions that rely on each other.

def with_transitions(
        self,
        *transitions: Union[
            Tuple[Union[str, list[str]], Union[str, list[str]]],
            Tuple[Union[str, list[str]], Union[str, list[str]], Condition],
        ],
    ) -> "GraphBuilder":
        """Adds transitions to the graph. Transitions are specified as tuples of either:
            1. (from, to, condition)
            2. (from, to)  -- condition is set to DEFAULT (which is a fallback)

        Transitions will be evaluated in order of specification -- if one is met, the others will not be evaluated.
        Note that one transition can be terminal -- the system doesn't have

        :param transitions: Transitions to add
        :return: The application builder for future chaining.
        """
        if self.transitions is None:
            self.transitions = []
        for transition in transitions:
            from_, to_, *conditions = transition
            if len(conditions) > 0:
                condition = conditions[0]
            else:
                condition = default
            if not isinstance(from_, list):
                from_ = [from_]
            if not isinstance(to_, list):
                to_ = [to_]
            for action_from in from_:
                for action_to in to_:
                    if not isinstance(action_from, str):
                        raise ValueError(
                            f"Transition source must be a string, not {action_from}"
                        )
                    if not isinstance(action_to, str):
                        raise ValueError(
                            f"Transition target must be a string, not {action_to}"
                        )
                    self.transitions.append((action_from, action_to, condition))
        return self

[skrawcz]

I think that should be enough. @elijahbenizzy right?

[post script] after Elijah's comment below, yeah what's the context that this would make sense for? [/post script]

[HamzaFarhan]

I want certain actions to loop until I'm satisfied with the result. But with a limit on the number of attempts.

[
    ("answer_question", "evaluate_answer"),
    # evaluate the answer and increment action_attempts if the evaluation is not satisfied and action_attempts is less than the limit
    (
        "evaluate_answer",
        ["increment_action_attempts", "answer_question"],
        ~expr("answer_evaluation.evaluation")
        & expr(f"action_attempts < {ACTION_ATTEMPTS_LIMIT}"),
    ),
    # if the evaluation is not satisfied and action_attempts is greater than or equal to the limit, reset action_attempts and go to the error_message action
    (
        "evaluate_answer",
        ["reset_action_attempts", "error_message"],
        ~expr("answer_evaluation.evaluation")
        & expr(f"action_attempts >= {ACTION_ATTEMPTS_LIMIT}"),
    ),
    # if the evaluation is satisfied, reset action_attempts and go to the final_message action
    (
        "evaluate_answer",
        ["reset_action_attempts", "final_message"],
        expr("answer_evaluation.evaluation"),
    ),
]

I can't go from evaluate_answer to increment_action_attempts and then from increment_action_attempts to the next action because increment_action_attempts would not know which action is being looped.

For now, I just increment or reset action_attempts at the end of evaluate_answer. But a standalone action would be better for reusability.

[HamzaFarhan]

Basically, how would I do this?

[HamzaFarhan]

I don't even need ACTION D. Just to go from A to B AND C.

[elijahbenizzy]

OK. So the way I'd model it is, given:

1. An input node (get_question, A)
2. An answering node (answer_question, B)
3. An evaluation node (evaluate_answer, C)
4. A final node (final, D)

A->B (always try to answer first)
B->C (then always evaluate the answer
C->B, if attempts < max_attempts (make sure C increments attempts as well, or stores a history of actions)
C->D if attempts >= max_attempts

Note that you could also go A->B, B->C, and C->A, while also going A->D if ready. I'm not 100% sure this captures your case though...

My issue with the phrasing of "AND" is it's really to a chain of them (which is fair), but AND could mean parallel, in series, etc... And it's not clear from this.

One other option to think about:

.with_actions(B_C=chain("B", "C"), ...)
.with_transitions(
  ("A", "B_C"),
  ("B_C", "B_C", expr(...))
  ("B_C", "D", ...)
)

[HamzaFarhan]

My current model is exactly the one that you have proposed.
I initially wanted a separate incrementer node instead of "make sure C increments attempts as well".
But yesterday I had to add some extra "action attempts logic" inside C. So having custom incrementing logic inside custom evaluator nodes seems like a better idea instead of a dedicated increment_attempts node.
I still think triggering n parallel actions from a single action could be useful. But not something I need right now.

[yiweig]

Hello! @elijahbenizzy (apologies if direct tagging is not considered good form here) I came across this discussion post while exploring burr for our use case. I have a similar question as OP, where I would explicitly like to define multiple transitions from A to both B and C -- except my use case would benefit from explicitly defining that B and C happen in parallel.

Is this currently possible? Looking at this discussion it doesn't seem so, but I want to make sure since OP's use case was solved a different way.

Happy to open this as a separate discussion if appropriate. Thanks!

[elijahbenizzy]

Hey @yiweig, direct tagging is OK. So this is all doable now, but we're actively making it easier. Currently, parallelism is done with recursive subgraphs. You launch n subgraphs using your own executor, and it's easy to wire through the tracker.

See the docs here.

We're currently building out the notion of a MapReduceAction that'll take state and map it to actions/subgraphs, then take the results and merge them back in the state. It'll make the above a lot simpler to do for the parallel use-case!

Planning this next week, probably release the week after (TBD, still scoping), but if you want to get started I'd run it in parallel (treating it as a sub-application/sub-graph). Going to open up a PR with a proposed API, and would love your feedback!

[skrawcz]

@yiweig to add to @elijahbenizzy's current approach to do it. The mental model is:

1. Define an action that uses something like job lib / multi-processing/ async gather /etc to do things in parallel.
2. To see it wired through in the UI you currently have to define a "Sub Application" (otherwise open telemetry should just work if it's an API call).

Your edge then is to that action that underneath does things in parallel. It is then responsible for using the right state and setting it back.

If it's two API calls you don't need the sub application part I don't think -- likely over kill; can you provide more info on what you want to make parallel? :) Otherwise we're working on making some of the ergonomics to make the simpler case easier -- and understanding use cases like yours would help.

[skrawcz]

FYI Parallelism V1 shipped with shipped with 0.33.0