fix(agentflow): prevent ConditionAgent silent failure when no scenario matches#5760
Conversation
… scenario matches the ConditionAgent was doing strict exact string matching against scenario descriptions, but LLMs often return abbreviated or slightly different versions of the scenario text. when nothing matched, all branches got marked as unfulfilled and the flow silently terminated with no response. added fallback matching (startsWith, includes) so partial matches still route correctly, plus a last-resort else branch so the flow never just dies silently. also added a safety net in the execution engine to catch the case where all conditions are unfulfilled. fixes FlowiseAI#5620
Summary of ChangesHello @aviu16, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical issue where the ConditionAgent could silently fail or loop indefinitely when an LLM's response didn't exactly match a scenario description. The changes introduce more flexible matching logic within the ConditionAgent to better interpret LLM outputs, along with a robust fallback mechanism that ensures a default path is always taken if no conditions are explicitly met, thereby improving the reliability and resilience of agent flows. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses a silent failure in the ConditionAgent by implementing more robust matching logic for LLM outputs. It introduces several fallback mechanisms, from exact string matching to substring checks, and finally defaults to an 'else' branch if no match is found. This significantly improves the reliability of conditional flows. A general safety net has also been added to buildAgentflow.ts to prevent flows from dying when no conditions are met in any decision node. The changes are well-reasoned and directly address the issue. My review includes suggestions to improve code quality and consistency.
packages/components/nodes/agentflow/ConditionAgent/ConditionAgent.ts
Outdated
Show resolved
Hide resolved
|
|
||
| // safety net: if no conditions were fulfilled, don't ignore ALL children | ||
| // treat the last condition as an else/default fallback | ||
| const anyFulfilled = outputConditions.some((c: any) => c.isFulfilled === true) |
There was a problem hiding this comment.
The type of c can be inferred from outputConditions which is ICondition[]. Explicitly typing it as any is unnecessary and reduces type-safety.
const anyFulfilled = outputConditions.some((c) => c.isFulfilled === true)There was a problem hiding this comment.
yeah removed those, inference handles it fine since outputConditions is already typed as ICondition[]
- normalize calledOutputName once before all matching steps instead of calling toLowerCase().trim() repeatedly - remove explicit any types where inference handles it
|
friendly follow-up: let me know if you want changes on this and I can patch quickly. |
|
added targeted unit coverage for the scenario-match fallback logic and extracted that logic into a small pure helper to make behavior explicit/testable.\n\nnew tests cover:\n- exact case-insensitive match\n- whitespace-trimmed match\n- startsWith fallback\n- substring fallback\n- final else-branch fallback\n\ntest run:\npnpm --filter flowise-components test -- nodes/agentflow/ConditionAgent/matchScenario.test.ts\npassed (6 tests). |
|
Friendly bump on this PR. When maintainers have a moment, could someone please take a look? Happy to make any requested changes quickly. Thanks! |
|
Implementation note: this fix focuses on removing the silent-failure path in ConditionAgent when no scenario matches, while keeping existing successful-match behavior intact. If maintainers want a narrower fallback strategy, I can revise quickly in this PR. |
HenryHengZJ
left a comment
HenryHengZJ
left a comment
There was a problem hiding this comment.
looks good thanks @aviu16 ! can you fix the linting issue with pnpm lint-fix ?
2 participants
fixes #5620
the ConditionAgent was doing a strict exact string match between the LLM response and the full scenario description text. LLMs (especially smaller models) often return abbreviated or slightly different versions, so the match would fail and ALL branches would be marked unfulfilled. this caused the flow to silently terminate with no response, or loop until hitting the max iteration limit.
whats changed:
before: sending "Hello" to a Router with GREETING/SQL/GENERAL scenarios would silently fail because the LLM returned something like "GREETING" instead of the full scenario description
after: the partial match catches it correctly, or worst case the else branch handles it