When using the chat-messages API, the “inputs” value seems to be cached and cannot be overwritten if the conversation is ongoing.

[mihit]

Self Checks

• This is only for bug report, if you would like to ask a question, please head to Discussions.
• 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).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• Please do not modify this template :) and fill in all the required fields.

Dify version

0.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Just do as the title.

✔️ Expected Behavior

I want to overwrite inputs.

❌ Actual Behavior

Never.

[dosubot]

There are a few similar discussions related to the issue you're experiencing with the "inputs" value in the chat-messages API:

1. The "inputs" field in the embedded app does not work - This discussion is still open and might provide insights or potential solutions.
2. Ensure the 'inputs' field in /chat-messages takes effect every time - This is another open discussion that could be relevant to your issue.
3. In preview chat, can I change the input parameters without restarting the chat conversation? - This discussion is also open and might offer useful information.

Regarding your issue, in Dify version 0.11.2, once a conversation_id is generated, any new "inputs" will be ignored in subsequent API calls. Only the query is processed for the ongoing conversation. To modify logic or variables during the session, you should use conversation variables (session-specific variables) to adjust the bot's behavior or responses ^[1][2].

To continue talking to Dosu, mention @dosu.

[crazywoola]

Duplicated, see the bot's reply, we are still reviewing this feature.

[liuzixiao666]

Duplicated, see the bot's reply, we are still reviewing this feature.

Can you reveal why this feature has been under discussion? What are the negative effects of this feature? I think it is a very important feature, and related competitors such as Coze, FastGPT, Maxkb all have related functions
My understanding here is that 'query' serves as the actual input of the user, while 'input' should be my explanation of the user's state. This is beneficial for the workflow to understand the current process that should be running and ensure that the user's actual dialogue input is not contaminated
For example, 'query'=[happy] hello, the workflow may reply with 'care' hello!, But I don't want [happy] to pollute the workflow's replies (mainly due to memory window issues)

[mihit]

@liuzixiao666
I would like to discuss the following points:

• APIs should clearly define their specifications as a fundamental principle.
• The name inputs does not explicitly indicate that input values are being cached. If this is the intended behavior, a more appropriate name such as persist_inputs would be better.
• Even though inputs are being cached and new input values are being discarded, the system does not inform the user about this.
  In other words, while I understand that caching inputs can be beneficial for certain use cases, I believe there are issues with the current implementation from a software perspective.

[liuzixiao666]

@liuzixiao666 I would like to discuss the following points:

• APIs should clearly define their specifications as a fundamental principle.
• The name inputs does not explicitly indicate that input values are being cached. If this is the intended behavior, a more appropriate name such as persist_inputs would be better.
• Even though inputs are being cached and new input values are being discarded, the system does not inform the user about this.
  In other words, while I understand that caching inputs can be beneficial for certain use cases, I believe there are issues with the current implementation from a software perspective.

thanks！！！！！

[glacierck]

It should not be cached. This is the only way to control the multi branch behavior flow by passing parameters from the outside. If you cache the outside, you cannot intervene in the session flow. And why cache it? Is there any problem with not caching?

[glacierck]

My RAG has multiple knowledge base branches that support users to select the loaded knowledge base from external settings and switch within the same Q&A process. Cache operations make everything impossible.