langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Inputs in difyChatbotConfig get lost if user clicks reset #7059

New Issue
Closed
opened 2026-02-21 18:18:38 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 18:18:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @polischool on GitHub (Dec 4, 2024).

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.13.0

Cloud or Self Hosted

Cloud

Steps to reproduce

Config to send variables from where its embedded so can be used as reference in the chat.
Fields appear and populate fine (though making them hidden would be MOST ideal)
Conversation starts using the input variables
User clicks reset
All input values are gone.

Keeping the input values always active (and making them hidden), is turning out to be vital for it to be used as a customer support option that needs basic user and account information pre-set in the conversation.

Would also be VERY nice to have the option to NOT allow users to view / change the input values set by difyChatbotConfig

✔️ Expected Behavior

Values from inputs remain so user can start new chat with the input values from difyChatbotConfig

❌ Actual Behavior

Input values disappear so have to hard-refresh the web browser to get them back and use in the conversation.

Originally created by @polischool on GitHub (Dec 4, 2024). ### Self Checks - [X] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.13.0 ### Cloud or Self Hosted Cloud ### Steps to reproduce Config to send variables from where its embedded so can be used as reference in the chat. Fields appear and populate fine (though making them hidden would be MOST ideal) Conversation starts using the input variables User clicks reset All input values are gone. Keeping the input values always active (and making them hidden), is turning out to be vital for it to be used as a customer support option that needs basic user and account information pre-set in the conversation. Would also be VERY nice to have the option to NOT allow users to view / change the input values set by difyChatbotConfig ### ✔️ Expected Behavior Values from inputs remain so user can start new chat with the input values from difyChatbotConfig ### ❌ Actual Behavior Input values disappear so have to hard-refresh the web browser to get them back and use in the conversation.
yindo added the 🐞 bug label 2026-02-21 18:18:38 -05:00
yindo closed this issue 2026-02-21 18:18:38 -05:00
yindo commented 2026-02-21 18:18:38 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 4, 2024):

I found a similar open issue that addresses the problem of input parameters being lost after clicking "Reset Conversation" in Dify. The suggested solution is to modify the handleRestart function or related logic to ensure that the input parameters are reapplied when the conversation is reset. This could involve storing the initial input parameters in a persistent state or variable that is not cleared during the reset process and then reapplying them when initializing the new session [1].

Additionally, the handleRestart function currently clears the conversation ID and task ID, stops any ongoing processes, resets iteration times, and initializes a new chat list based on the configuration's opening statement. It does not currently handle the persistence of input parameters across resets [2].

To address your need for keeping input values active and potentially hidden, you might consider implementing a mechanism to store these values in a persistent state that survives session resets. Unfortunately, I couldn't find specific information on hiding input fields while retaining their values, but you might explore custom modifications to the input handling logic to achieve this.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Dec 4, 2024): <!-- Answer --> I found a similar open issue that addresses the problem of input parameters being lost after clicking "Reset Conversation" in Dify. The suggested solution is to modify the `handleRestart` function or related logic to ensure that the input parameters are reapplied when the conversation is reset. This could involve storing the initial input parameters in a persistent state or variable that is not cleared during the reset process and then reapplying them when initializing the new session <sup>[[1]](https://github.com/langgenius/dify/issues/11025)</sup>. Additionally, the `handleRestart` function currently clears the conversation ID and task ID, stops any ongoing processes, resets iteration times, and initializes a new chat list based on the configuration's opening statement. It does not currently handle the persistence of input parameters across resets <sup>[[2]](https://github.com/langgenius/dify/blob/main/web/app/components/base/chat/chat/hooks.ts)</sup>. To address your need for keeping input values active and potentially hidden, you might consider implementing a mechanism to store these values in a persistent state that survives session resets. Unfortunately, I couldn't find specific information on hiding input fields while retaining their values, but you might explore custom modifications to the input handling logic to achieve this. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:18:39 -05:00
Author
Owner
Copy Link
Copy Source

@polischool commented on GitHub (Dec 4, 2024):

This is Cloud hosted, so we have no control over the code (unless that is an option I'm not seeing when initializing)

@polischool commented on GitHub (Dec 4, 2024): This is Cloud hosted, so we have no control over the code (unless that is an option I'm not seeing when initializing)
yindo commented 2026-02-21 18:18:39 -05:00
Author
Owner
Copy Link
Copy Source

@ShadowL360 commented on GitHub (Dec 4, 2024):

I have the same issue. I’ve already tried fixing this bug but haven’t had any success so far.

@ShadowL360 commented on GitHub (Dec 4, 2024): I have the same issue. I’ve already tried fixing this bug but haven’t had any success so far.
yindo commented 2026-02-21 18:18:39 -05:00
Author
Owner
Copy Link
Copy Source

@polischool commented on GitHub (Dec 4, 2024):

I can't see how to pull off using it as a help tool if it can't get input variables from the location on which the original script is embedded. Is there a secret out there I haven't found yet to accomplish what feels like a simple task: have the workflow start so that it includes the domain and a few more variables that are applicable to the user? (i've tried somehow using the ID of the script and adding data-domain, data-firstname, etc. and then getAttribute as a code block in the workflow, but that always makes the entire thing fail, so am at a total loss other than reliable (and hidden, and unchangeable) inputs. Hoping someone smarter than me knows the secret.

@polischool commented on GitHub (Dec 4, 2024): I can't see how to pull off using it as a help tool if it can't get input variables from the location on which the original script is embedded. Is there a secret out there I haven't found yet to accomplish what feels like a simple task: have the workflow start so that it includes the domain and a few more variables that are applicable to the user? (i've tried somehow using the ID of the script and adding data-domain, data-firstname, etc. and then getAttribute as a code block in the workflow, but that always makes the entire thing fail, so am at a total loss other than reliable (and hidden, and unchangeable) inputs. Hoping someone smarter than me knows the secret.
yindo commented 2026-02-21 18:18:39 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 4, 2024):

Duplicated https://github.com/langgenius/dify/issues/11025

@crazywoola commented on GitHub (Dec 4, 2024): Duplicated https://github.com/langgenius/dify/issues/11025
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#7059
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?