Skip to content

Mb/func simple handle run in parallel #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

markbackman
Copy link
Contributor

The changes from #145 on top of the function simplification changes.

kompfner added 30 commits June 12, 2025 09:28
… provide Python functions as NodeConfig functions.

When direct functions are used:
- Function name, description, properties, and required are all automatically read from the Python function signature and docstring
- There’s no need for separate handler and transition callbacks
…ot be conflated with being required (that should happen by way of a default argument)
…working! Still more work to do before it’s ready, though
…f “unified” functions (functions that return both result and next_node, obviating the need to use `transition_to`/`transition_callback`) and “direct” functions (functions that are provided in lieu of function declarations/`FlowsFunctionSchema`s, and whose metadata is parsed out automatically from its signature and docstring). This allows the user to pass a "unified" function as a `handler` and simply omit `transition_to`/`transition_callback` without necessarily opting out of function declarations/`FlowsFunctionSchema`s.
…nified function the next node's name alongside its `NodeConfig`, to facilitate debug logging
…rst parameter of direct functions rather the last, so that if any of the other parameters are optional the user doesn't have to awkwardly specify a default value for `flow_manager`
…ecking validation that `flow_manager` argument is in the right place
…wResult`s from direct functions exercised in unit tests
kompfner and others added 17 commits June 12, 2025 09:28
…ise non-required parameters (specifically, to ensure that `Optional` and not required are not the same)
…to `NodeConfig` so that we don't have to have the awkward `NamedNode`
…and `transition_callback` in favor of "consolidated" `handler` functions that return a tuple (result, next_node)
… an initial node, obviating the need for the user to call `set_node` directly; this change feels important to do now that we've added the `name` field to `NodeConfig` so that users don't end up confusingly specifying (potentially different) names in their `NodeConfig`s as in their `set_node` calls
…e()`"

This reverts commit 284e464.

It turns out that `set_node()` is useful outside of the function lifecycle; it's used, for example, in the warm transfer demo in an `on_participant_joined` handler (when the human agent joins)
…)`, an alternative to `set_node()` that doesn't require the customer to provide a node name, since they can do so from within their node config.

Hopefully users won't need to directly set nodes often, what with the introduction of:
- "consolidated" functions that return the next node, eliminating the need for transition callbacks
- `initialize()` taking the initial node

`set_node_from_config()` is a bit clunky, but I couldn’t find a way to reuse `set_node()` without breaking API compatibility. There are ways of fudging method overloading in Python, but not without breaking keyword-argument-based invocation, it seems.
…ke 2). This time we have an alternative: `set_node_from_config()`.
Copy link

vercel bot commented Jun 13, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
pipecat-flows ✅ Ready (Inspect) Visit Preview Jun 13, 2025 4:10pm

@markbackman
Copy link
Contributor Author

Closing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants