Conversation
…n increment to 1.1 - Added a new input parameter 'fallbackMessage' to the Loop Agentflow for displaying a message when the loop count is exceeded. - Incremented the version of Loop Agentflow from 1.0 to 1.1. - Updated the processing logic to handle the fallback message appropriately when the maximum loop count is reached.
…g the runtime state during workflow execution. - Added a method to list runtime state keys for dynamic state management. - Implemented logic to retrieve and utilize the current loop count in variable resolution. - Updated the Loop Agentflow output to reflect the new state and final output content.
|
This new addition allows user to specify fallback message after loop is exhaused, and use the new built in variable 
The ideal way is to allow Loop node to have 2 outputs, 1 to loopback, 1 to fallback, but since we are not able to have the loopback edges, thus having just 1 fallback outgoing path is going to confuse user. Hence, we'd prefer to stick with no outgoing paths 
|
|
@HenryHengZJ following the conversation from here #4653 (comment), if what we want is simplicity for new users, the visual approach with 1 ouput works better, IMHO. This allows us to add a simple reply node, as we do in other nodes, or of if needed, create much more advanced applications by adding whatever new workflow logic we can implement after exhaustion. I don't know, it feels quite intuitive to me and provides a new dimension to the flow that it currently does not have.
I know you want to get this simple, but this draft implementation I did took me 45 mins (only 2 files), just the time I needed to figure out the loop counting, but of course, as always, this is up to you. Maybe a new toggle option to disable the visual output by default? |
|
|
|
Good suggestion, I think the best approach is to add another toggle option - |
|
@HenryHengZJ For what it's worth, I have aligned the fallback implementation (now working in all the scenarios and nodes I tested out) with the original code main...toi500:Flowise:exhausted-output-loop-node, making only minimal and targeted changes. If you want, I can make a draft PR so you can wrap this out with that new UI dynamic capability to make the fallback output disabled by default. |
|
thanks, that's fine we dont have to open a draft PR, I can just refer to the link you pasted |
|
merging this one and will open separate PR for adding |
* Feature: Update Loop Agentflow to include fallback message and version increment to 1.1 - Added a new input parameter 'fallbackMessage' to the Loop Agentflow for displaying a message when the loop count is exceeded. - Incremented the version of Loop Agentflow from 1.0 to 1.1. - Updated the processing logic to handle the fallback message appropriately when the maximum loop count is reached. * - Introduced a new input parameter 'loopUpdateState' to allow updating the runtime state during workflow execution. - Added a method to list runtime state keys for dynamic state management. - Implemented logic to retrieve and utilize the current loop count in variable resolution. - Updated the Loop Agentflow output to reflect the new state and final output content.
* Feature: Update Loop Agentflow to include fallback message and version increment to 1.1 - Added a new input parameter 'fallbackMessage' to the Loop Agentflow for displaying a message when the loop count is exceeded. - Incremented the version of Loop Agentflow from 1.0 to 1.1. - Updated the processing logic to handle the fallback message appropriately when the maximum loop count is reached. * - Introduced a new input parameter 'loopUpdateState' to allow updating the runtime state during workflow execution. - Added a method to list runtime state keys for dynamic state management. - Implemented logic to retrieve and utilize the current loop count in variable resolution. - Updated the Loop Agentflow output to reflect the new state and final output content.
2 participants
Include fallback message and version increment to 1.1