feat(agentflow): add client filtering for form input options in Start node#6212
Conversation
… node - Enhanced Start node to include a client property for the form input option, allowing differentiation between 'agentflowv2' and 'agentflowsdk'. - Added tests to verify that the 'formInput' option is correctly filtered based on the client type.
![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 restricts the 'Form Input' option in the Start node to the 'agentflowv2' client and introduces unit tests to verify the filtering logic for different clients. Feedback suggests improving the test assertions by using toMatchObject and checking the exact length of the options array to ensure consistency with existing tests and avoid unnecessary type casting.
| name: 'formInput', | ||
| description: 'Start the workflow with form inputs' | ||
| description: 'Start the workflow with form inputs', | ||
| client: ['agentflowv2'] |
There was a problem hiding this comment.
didn't bump the version since there is no change to the runtime schema
There was a problem hiding this comment.
what does client means? I wonder instead of making the changes here in OSS, should we create a new node in extension that extends the original Start class, but override the params to exclude formInput.
my main concern is that if we make changes here, this cllient value will get stored in every saved flow moving forward for every users, making it hard in future if we want to get rid/make further changes
There was a problem hiding this comment.
(shared the tech doc offline)
The client field was introduced in PR #6107 as a general-purpose mechanism for scoping node params/options per client (agentflowv2 vs agentflowsdk). It lives on the param definition (schema), not on saved flow data — filterNodeByClient() on the server strips it before sending the API response, so it never gets stored in flows.
The extension approach would work too, but it means maintaining a parallel Start node that needs to stay in sync with the OSS one. Since the client filtering infrastructure is already in place and doesn't affect saved data, this felt like the lighter-weight path.
Let me know if this makes sense to you or if you still prefer strongly to go with the extension route.
2 participants
FLOWISE-510
start-node-limit-form-input-client.mov