Skip to content
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

Update ConditionalRouter.run method to check the rendered output matches the defined output_type #8445

Open
sjrl opened this issue Oct 8, 2024 · 0 comments
Assignees
Labels
P1 High priority, add to the next sprint type:feature New feature or request

Comments

@sjrl
Copy link
Contributor

sjrl commented Oct 8, 2024

I really like the ConditionalRouter since it enables a lot of agentic type use cases. However, it can be a little difficult to use since it relies on good knowledge of Jinja2 syntax and I have found in practice it's very easy to make mistakes and errors. So to partially help this process I think it would be great if we could add a check to the run method.

For example, I'd like the ConditionalRouter.run method to check that the output from the selected condition actually matches the specified type in output_type. For example,

from haystack.components.routers.conditional_router import ConditionalRouter

c = ConditionalRouter(
    [
        {"condition": "{{streams|length < 2}}", "output": "{{query}}", "output_type": str, "output_name": "query"},
        {
            "condition": "{{streams|length >= 2}}",
            "output": "{{streams}}",
            "output_type": "str",
            "output_name": "streams",
        },
    ]
)

kwargs = {"streams": [1, 2, 3], "query": "Haystack"}
result = c.run(**kwargs)
print(result)
# {'streams': [1, 2, 3]}. --> Still a list of integers

Instead of still returning streams with the wrong output type it'd be great if the Conditional Router could throw an error (or at the very least a warning) if the output [1, 2, 3] doesn't match the output type. This would make debugging a lot easier since it identifies this issue early on and not later down the road when this output eventually causes an error downstream in some other component I've connected it to.

@julian-risch julian-risch added P2 Medium priority, add to the next sprint if no P1 available type:feature New feature or request labels Oct 14, 2024
@julian-risch julian-risch added P1 High priority, add to the next sprint and removed P2 Medium priority, add to the next sprint if no P1 available labels Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 High priority, add to the next sprint type:feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants