[Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input.

[superswxwb]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

v0.19.0

RAGFlow image version

v0.19.0

Other environment information

Actual behavior

agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input.

Expected behavior

repair docker

Steps to reproduce

agent categorize node v0.18.0 is ok , but the  v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input.

Additional information

No response

[dosubot]

Hi @superswxwb! I'm Dosu and I’m helping the ragflow team.

Based on the code for RAGFlow v0.19.0, the inference of component inputs for the agent categorize node is handled by the get_input() method in agent/component/base.py. This method tries to fetch outputs from upstream components and queries, but it contains logic that skips using outputs from upstream nodes of type "categorize" (and "relevant") as inputs unless certain conditions are met. If it cannot infer the input, it raises an assertion error: "Can't inference the where the component input is. Please identify whose output is this component's input." [source].

There is no evidence of changes to this inference logic between v0.18.0 and v0.19.0, so the mechanism is likely unchanged. This suggests the issue may be due to configuration, missing connections, or changes in how the workflow is wired, rather than a code regression.

To resolve this, check that the categorize node is explicitly connected to the correct upstream component and that the input parameters (queries) are set up as expected. If you are running in Docker, ensure your workspace and configuration files are correctly mounted and not using cached or outdated settings.

No existing issues or discussions in the repository directly address this specific problem. If you continue to encounter this error, review your workflow setup to ensure all necessary connections are present and correctly configured.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[superswxwb]

i try this ok. another question; i want to bring parameter to workflow the repair string is: ### 查询语句中相关变量需要进行替换: ***@***.***_parameter} if run in the editor, it's ok i can get the right sql select zcmc, count(1) as zcsl from prd_zcall where syrbh = 'C11025' and gbflh in (select distinct gbflh from prd_zcall where zcmc like '%电脑%') group by zcmc; but i use it in iframe http://192.168.1.66/chat/share?shared_id=38277622403f11f08a540242ac120006&from=agent&auth=FmMGRkODEwNDA0MDExZjBhNzFmMDI0Mm&locale=zh&repair_parameter='当前用户' 替换为 'C11025'，'人员编号' 替换为 'admin_jcc' or http://192.168.1.66/chat/share?shared_id=38277622403f11f08a540242ac120006&from=agent&auth=FmMGRkODEwNDA0MDExZjBhNzFmMDI0Mm&locale=zh&repair_parameter=%E5%B0%86%22%E5%BD%93%E5%89%8D%E7%94%A8%E6%88%B7%22%20%E6%9B%BF%E6%8D%A2%E4%B8%BA%20%22C11025%22%EF%BC%8C%E5%B0%86%22%E4%BA%BA%E5%91%98%E7%BC%96%E5%8F%B7%22%20%E5%88%99%E6%8A%8A%E5%AE%83%E6%9B%BF%E6%8D%A2%E4%B8%BA%20%22admin_jcc%22 select zcmc, count(1) as zcsl from prd_zcall where syrbh = '当前用户' and gbflh in (select distinct gbflh from prd_zcall where zcmc like '%电脑%') group by zcmc; i think the repair_parameter not work, and v0.18 i'ts ok, How to solve it thanks ***@***.*** From: dosubot[bot] Date: 2025-06-02 23:25 To: infiniflow/ragflow CC: superswxwb; Mention Subject: Re: [infiniflow/ragflow] [Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input. (Issue #8006) dosubot[bot] left a comment (infiniflow/ragflow#8006) Hi @superswxwb! I'm Dosu and I’m helping the ragflow team. Based on the code for RAGFlow v0.19.0, the inference of component inputs for the agent categorize node is handled by the get_input() method in agent/component/base.py. This method tries to fetch outputs from upstream components and queries, but it contains logic that skips using outputs from upstream nodes of type "categorize" (and "relevant") as inputs unless certain conditions are met. If it cannot infer the input, it raises an assertion error: "Can't inference the where the component input is. Please identify whose output is this component's input." [source]. There is no evidence of changes to this inference logic between v0.18.0 and v0.19.0, so the mechanism is likely unchanged. This suggests the issue may be due to configuration, missing connections, or changes in how the workflow is wired, rather than a code regression. To resolve this, check that the categorize node is explicitly connected to the correct upstream component and that the input parameters (queries) are set up as expected. If you are running in Docker, ensure your workspace and configuration files are correctly mounted and not using cached or outdated settings. No existing issues or discussions in the repository directly address this specific problem. If you continue to encounter this error, review your workflow setup to ensure all necessary connections are present and correctly configured. To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

The issue is that the repair_parameter works in the editor but not when using the iframe embed. Based on the available code and documentation, there is no special handling for a parameter named repair_parameter in the backend or frontend. Instead, RAGFlow supports passing generic parameters to workflows via URL query parameters, but only if the workflow and backend are set up to recognize and use them.

For iframes, the officially supported way to pass parameters is to use the format /chat/share?...&data_xx=testing, where data_xx is the parameter name and testing is the value. This method is documented and works in v0.17.2 and above, but there is no mention of repair_parameter as a recognized or reserved parameter name in the code or docs. If you want to pass a value for "当前用户", you should use a parameter like &data_当前用户=C11025 in your iframe URL. For example:

http://192.168.1.66/chat/share?shared_id=...&from=agent&auth=...&locale=zh&data_当前用户=C11025&data_人员编号=admin_jcc

Your workflow or SQL template must reference these parameters using the correct variable names (for example, {data_当前用户}) for the replacement to work. If your workflow is expecting repair_parameter, you may need to update it to use the data_xx convention instead, as this is what the backend expects and processes for iframe embeds reference.

There is no evidence of changes between v0.18.0 and v0.19.0 that would affect this mechanism, but the frontend embed modal and backend handlers do not reference repair_parameter anywhere, so it is likely that this only worked previously due to a side effect or undocumented behavior.

To resolve the issue, update your iframe URLs to use the data_xx format for parameters, and ensure your workflow templates reference those variables. If you need to pass multiple parameters, add each as a separate data_xx query parameter.

If you need more advanced parameter mapping or have a legacy workflow that expects repair_parameter, you may need to adjust your workflow logic to match the supported parameter passing mechanism.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[superswxwb]

i change the parameter set like this: if the Optional is true, the work flow is right, but not get parameter if the Optional is true, the work flow is disable, like this That means I didn't pass the parameters correctly, but I can with V0.18.0 help me , thanks ***@***.*** From: dosubot[bot] Date: 2025-06-03 18:04 To: infiniflow/ragflow CC: superswxwb; Mention Subject: Re: [infiniflow/ragflow] [Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input. (Issue #8006) dosubot[bot] left a comment (infiniflow/ragflow#8006) The issue is that the repair_parameter works in the editor but not when using the iframe embed. Based on the available code and documentation, there is no special handling for a parameter named repair_parameter in the backend or frontend. Instead, RAGFlow supports passing generic parameters to workflows via URL query parameters, but only if the workflow and backend are set up to recognize and use them. For iframes, the officially supported way to pass parameters is to use the format /chat/share?...&data_xx=testing, where data_xx is the parameter name and testing is the value. This method is documented and works in v0.17.2 and above, but there is no mention of repair_parameter as a recognized or reserved parameter name in the code or docs. If you want to pass a value for "当前用户", you should use a parameter like &data_当前用户=C11025 in your iframe URL. For example: http://192.168.1.66/chat/share?shared_id=...&from=agent&auth=...&locale=zh&data_当前用户=C11025&data_人员编号=admin_jcc Your workflow or SQL template must reference these parameters using the correct variable names (for example, {data_当前用户}) for the replacement to work. If your workflow is expecting repair_parameter, you may need to update it to use the data_xx convention instead, as this is what the backend expects and processes for iframe embeds reference. There is no evidence of changes between v0.18.0 and v0.19.0 that would affect this mechanism, but the frontend embed modal and backend handlers do not reference repair_parameter anywhere, so it is likely that this only worked previously due to a side effect or undocumented behavior. To resolve the issue, update your iframe URLs to use the data_xx format for parameters, and ensure your workflow templates reference those variables. If you need to pass multiple parameters, add each as a separate data_xx query parameter. If you need more advanced parameter mapping or have a legacy workflow that expects repair_parameter, you may need to adjust your workflow logic to match the supported parameter passing mechanism. To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

Your issue is caused by how RAGFlow expects parameters to be passed in iframes in v0.19.0. The parameter repair_parameter is not recognized by the backend or frontend in either v0.18.0 or v0.19.0. In v0.19.0, you must use the data_xx format in your iframe URL, for example: &data_当前用户=C11025&data_人员编号=admin_jcc. Your workflow or SQL template must reference these as {data_当前用户} and {data_人员编号} for the replacement to work. If you use repair_parameter, it will not be picked up by the workflow logic in v0.19.0, even if it may have worked by accident in v0.18.0 due to undocumented behavior or a bug source.

About the Optional setting: if a parameter is marked as optional, the workflow will not fail if it is missing, but it also will not receive a value unless you pass it correctly. If the parameter is not optional and you do not provide it, the workflow will be disabled or error out source.

There are no changes between v0.18.0 and v0.19.0 in how parameters are passed to iframes or how the Optional setting works, according to the release notes and code review. The correct and only supported way is to use data_xx in the URL and reference those variables in your workflow template source.

To fix your issue:

1. Change your iframe URL to use &data_当前用户=C11025&data_人员编号=admin_jcc.
2. Update your workflow template to use {data_当前用户} and {data_人员编号} as variables.
3. Make sure the Optional setting matches your needs: enabled if the parameter can be missing, disabled if it must be provided.

If you follow this, parameter passing in v0.19.0 should work as expected.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[superswxwb]

i changed my work flow like this: ### 查询语句中有相关变量需要进行替换: ***@***.***_user_current}, ***@***.***_user_id} and save like this: so i want use "http://192.168.1.66/chat/share?shared_id=676038c4406811f092560242ac120006&from=agent&auth=FmMGRkODEwNDA0MDExZjBhNzFmMDI0Mm&data_user_current=C11025&data_user_id=admin_jcc" to visit, but get this if right the '当前用户' must be change to 'C11025' , So parameter transfer failed ***@***.*** From: dosubot[bot] Date: 2025-06-04 11:12 To: infiniflow/ragflow CC: superswxwb; Mention Subject: Re: [infiniflow/ragflow] [Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input. (Issue #8006) dosubot[bot] left a comment (infiniflow/ragflow#8006) Your issue is caused by how RAGFlow expects parameters to be passed in iframes in v0.19.0. The parameter repair_parameter is not recognized by the backend or frontend in either v0.18.0 or v0.19.0. In v0.19.0, you must use the data_xx format in your iframe URL, for example: &data_当前用户=C11025&data_人员编号=admin_jcc. Your workflow or SQL template must reference these as {data_当前用户} and {data_人员编号} for the replacement to work. If you use repair_parameter, it will not be picked up by the workflow logic in v0.19.0, even if it may have worked by accident in v0.18.0 due to undocumented behavior or a bug source. About the Optional setting: if a parameter is marked as optional, the workflow will not fail if it is missing, but it also will not receive a value unless you pass it correctly. If the parameter is not optional and you do not provide it, the workflow will be disabled or error out source. There are no changes between v0.18.0 and v0.19.0 in how parameters are passed to iframes or how the Optional setting works, according to the release notes and code review. The correct and only supported way is to use data_xx in the URL and reference those variables in your workflow template source. To fix your issue: Change your iframe URL to use &data_当前用户=C11025&data_人员编号=admin_jcc. Update your workflow template to use {data_当前用户} and {data_人员编号} as variables. Make sure the Optional setting matches your needs: enabled if the parameter can be missing, disabled if it must be provided. If you follow this, parameter passing in v0.19.0 should work as expected. To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

In RAGFlow v0.19.0, passing custom parameters to workflows via iframe URLs is now restricted. Only fixed, UI-exposed options like locale and avatar visibility are supported for iframe embedding. Custom variables such as data_user_current or data_user_id in the URL will not be recognized or injected into your workflow as they may have been in v0.18.0. This is a deliberate change to tighten security and control over iframe integrations, and is documented in the official guides and reflected in the codebase [embed agent into webpage].

If your workflow requires variables (for example, to replace '当前用户' with 'C11025'), you must now set these variables using the API or Python SDK, not via iframe URL parameters. The iframe embed is only supported for agents that do not require custom variables in their "Begin" component. If your agent's workflow requires variables, embedding via iframe will not work as expected [source].

If you need to pass dynamic variables, consider switching to the API or SDK integration, where you can explicitly set all required parameters. The iframe method is now only for simple, variable-free agents.

If you have further questions about API or SDK usage for parameterized workflows, let me know!

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[superswxwb]

so bad i want to use https embed the url keep the security. So I want you to open up the settings, otherwise I will go back v0.18.0, but v0.18.0 has an other question ,in work flow the first ask is empty, until the second ask, the answer is right. but this question in v0.19.0 is right. So I want you to open up the settings thanks ***@***.*** From: dosubot[bot] Date: 2025-06-04 11:24 To: infiniflow/ragflow CC: superswxwb; Mention Subject: Re: [infiniflow/ragflow] [Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input. (Issue #8006) dosubot[bot] left a comment (infiniflow/ragflow#8006) In RAGFlow v0.19.0, passing custom parameters to workflows via iframe URLs is now restricted. Only fixed, UI-exposed options like locale and avatar visibility are supported for iframe embedding. Custom variables such as data_user_current or data_user_id in the URL will not be recognized or injected into your workflow as they may have been in v0.18.0. This is a deliberate change to tighten security and control over iframe integrations, and is documented in the official guides and reflected in the codebase [embed agent into webpage]. If your workflow requires variables (for example, to replace '当前用户' with 'C11025'), you must now set these variables using the API or Python SDK, not via iframe URL parameters. The iframe embed is only supported for agents that do not require custom variables in their "Begin" component. If your agent's workflow requires variables, embedding via iframe will not work as expected [source]. If you need to pass dynamic variables, consider switching to the API or SDK integration, where you can explicitly set all required parameters. The iframe method is now only for simple, variable-free agents. If you have further questions about API or SDK usage for parameterized workflows, let me know! To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

The restriction on passing custom parameters via iframe URLs in RAGFlow v0.19.0 is a deliberate security measure. Only fixed, UI-exposed options like locale and avatar visibility are supported for iframe embedding. Custom variables such as data_user_current or data_user_id in the URL are not recognized or injected into your workflow as they may have been in v0.18.0. This change was made to tighten security and prevent potential injection attacks or misuse of embedded agents [source].

If your workflow requires variables (for example, to replace '当前用户' with 'C11025'), you now need to set these variables using the API or Python SDK, not via iframe URL parameters. The iframe embed is only supported for agents that do not require custom variables in their "Begin" component [source].

Using the API or SDK is the recommended and secure way to pass parameters. The API requires authentication (API key), validates all parameters, and supports secure, flexible parameter management. The Python SDK provides similar capabilities and is easy to integrate into your backend or web application [source][source].

There are no settings in v0.19.0 to re-enable custom parameter passing via iframe for security reasons. If you require dynamic variables, you must use the API or SDK.

Regarding v0.18.0: the issue where the first ask is empty and only the second ask returns the correct answer is a known limitation, but there is no official workaround documented. This issue is resolved in v0.19.0, but v0.19.0 enforces the new security model for parameter passing [source].

If you need to keep using HTTPS and embedding for security, the API/SDK approach is the only supported and secure method for parameterized workflows in v0.19.0. If you have further questions about using the API or SDK for your use case, let me know.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[superswxwb]

i wan to use the easy way. but now only to invoke API , Our team is difficult to talk to, can you give me a simple call case? My Ragflow is deployed in a Docker environment. thanks ***@***.*** From: dosubot[bot] Date: 2025-06-04 11:52 To: infiniflow/ragflow CC: superswxwb; Mention Subject: Re: [infiniflow/ragflow] [Bug]: agent categorize node v0.18.0 is ok , but the v0.19.0 Can't inference the where the component input is. Please identify whose output is this component's input. (Issue #8006) dosubot[bot] left a comment (infiniflow/ragflow#8006) The restriction on passing custom parameters via iframe URLs in RAGFlow v0.19.0 is a deliberate security measure. Only fixed, UI-exposed options like locale and avatar visibility are supported for iframe embedding. Custom variables such as data_user_current or data_user_id in the URL are not recognized or injected into your workflow as they may have been in v0.18.0. This change was made to tighten security and prevent potential injection attacks or misuse of embedded agents [source]. If your workflow requires variables (for example, to replace '当前用户' with 'C11025'), you now need to set these variables using the API or Python SDK, not via iframe URL parameters. The iframe embed is only supported for agents that do not require custom variables in their "Begin" component [source]. Using the API or SDK is the recommended and secure way to pass parameters. The API requires authentication (API key), validates all parameters, and supports secure, flexible parameter management. The Python SDK provides similar capabilities and is easy to integrate into your backend or web application [source][source]. There are no settings in v0.19.0 to re-enable custom parameter passing via iframe for security reasons. If you require dynamic variables, you must use the API or SDK. Regarding v0.18.0: the issue where the first ask is empty and only the second ask returns the correct answer is a known limitation, but there is no official workaround documented. This issue is resolved in v0.19.0, but v0.19.0 enforces the new security model for parameter passing [source]. If you need to keep using HTTPS and embedding for security, the API/SDK approach is the only supported and secure method for parameterized workflows in v0.19.0. If you have further questions about using the API or SDK for your use case, let me know. To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other ― Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>