Ensure the 'inputs' field in /chat-messages takes effect every time

[crazywoola]

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).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• Please do not modify this template :) and fill in all the required fields.

Content

Regarding this PR request, we are looking for the feedback from the community. Either testing it or feedbacks are welcome.

#7955

If you support this feature, please leave a 👍 in this discussion. Or leave 👀 if you don't support it or you have something to say.

[Wu-Jiayang]

I would like to ask why you decided to fix the 'inputs' field during the design?

[crazywoola]

Maybe like a snapshot, I think in a very early stage, we were putting more effort in completion app, so it's more like a one time workflow at this moment.

[Wu-Jiayang]

I see. This is my first time submitting a PR to an open-source project. If you decide to merge it, will I become a Contributor?

[liuzixiao666]

At present, we need different responses for visits from different customers at different times and locations, so our agent needs to obtain this part of the variables in advance. Previously, our variables were in the input variable, but we found that we can only guarantee the variables at the beginning of the session. If the state changes later, we still cannot make the same response in a timely manner. If we follow the feedback in real time, we must open a new session, which will cause short-term memory failure. For example, when a user asks about a certain product, we introduce the price and other information of the product. During this process, our product may have been sold out, but the agent cannot know. If the user still wants to ask, the agent will inform them that they can purchase it. It is not realistic to store the real-time status of products in a knowledge base, and embedding it in a workflow using HTTP requests requires ensuring the correctness of many parameters, which places high demands on our development

[liuzixiao666]

At present, we need different responses for visits from different customers at different times and locations, so our agent needs to obtain this part of the variables in advance. Previously, our variables were in the input variable, but we found that we can only guarantee the variables at the beginning of the session. If the state changes later, we still cannot make the same response in a timely manner. If we follow the feedback in real time, we must open a new session, which will cause short-term memory failure. For example, when a user asks about a certain product, we introduce the price and other information of the product. During this process, our product may have been sold out, but the agent cannot know. If the user still wants to ask, the agent will inform them that they can purchase it. It is not realistic to store the real-time status of products in a knowledge base, and embedding it in a workflow using HTTP requests requires ensuring the correctness of many parameters, which places high demands on our development

At the same time, I accept that some fields only need to be entered once, such as customer basic information, and some fields support real-time changes, such as the current customer status

[dreamTrainer]

I need this feature.

[liuxin19971202]

Is this feature finally going to be released? I am still using FastGPT and hope to update dify as soon as possible!!!

[HaiShin]

I hope that each time the /chat-message interface is called, new inputs can be used instead of a one-time input. Because I hope that it can obtain the page cookies in real time to determine whether the login has expired. Or it can provide more intelligent Q&A by judging the content of the page.

[mihit]

#11140
I asked a question here as well.
Frankly speaking, I mistook the current implementation for a bug. Because the interface looks different from the behavior we expect.
I think that inputs that you want to persist should be isolated in a field for that purpose, like "persist_inputs", and any request that tries to overwrite them should raise an Exception.

[Wu-Jiayang]

My thought is exactly the same as you!

[Wu-Jiayang]

You can see my PR #7955
I tested it on v0.11.1. It works well.