Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Missing chat history after restart flow is invoked #282

Open
alexpeelman opened this issue Dec 9, 2024 · 2 comments · May be fixed by #283
Open

[Bug] Missing chat history after restart flow is invoked #282

alexpeelman opened this issue Dec 9, 2024 · 2 comments · May be fixed by #283
Assignees
Labels
bug Something isn't working

Comments

@alexpeelman
Copy link

Bug Description:

Depending on the scenario this might be a bug or expected behaviour.

My use case is as follows :

  • A user starts chatting with the bot
  • The user clicks a custom reset button invoking restartFlow
  • Immediately afterwards the user clicks load chat history

What I expect is that all messages are loaded up to the point before the reset button was clicked, but this is not the case. The bot only loads older messages based on the storage state when the component was created. The new messages are missing.

When going through the code this is expected behaviour.

Inside ChatHistoryService.tsx at the end of saveChatHistory function, calling setHistoryMessages ensures that storage is updated with the new messages. Unfortunately let historyMessages: Message[] = []; is now out of sync with what is serialised to storage.

Continuing my hunt , I see that loadChatHistory is responsible for populating the messages, but it takes chatHistory: Message[] as an argument. Which brings me to useChatHistoryInternal.ts that uses const chatHistory = getHistoryMessages() to pass it as argument value.

What I see here is that getHistoryMessages() is returning the out of sync values because it uses the historyMessages variable from ChatHistoryService.tsx.

My guess is that the parsedMessages should just be assigned to historyMessages before storing it in storage and we are good ?
I am happy to implement this change.

Expected behavior:

After restartFlow is invoked and load history is clicked load all historical messages, even the most recent ones.

Screenshots:

This first screenshot shows the stored history messages before restartFlow is invoked
chat-history-before-restart

This second screenshot shows the stored history messages after restartFlow is invoked. What you notice is that the last messages are gone.
chat-history-after-restart

Library version:
^2.0.0-beta.26

Desktop (please complete the following information):

  • Browser: [chrome]
@alexpeelman alexpeelman added the bug Something isn't working label Dec 9, 2024
@alexpeelman alexpeelman linked a pull request Dec 9, 2024 that will close this issue
7 tasks
@tjtanjin
Copy link
Owner

tjtanjin commented Dec 9, 2024

Hey @alexpeelman! Thank you for taking the time to dive into the mess and for the detailed breakdown 🥹

You're right to point out that the current logic overlooks chat history when resetting flow! I see you've made a PR with a potential fix, though that one line introduced another issue of its own 😰

In brief, the variable historyMessages is used to hold the set of messages that should be loaded when the load history button is clicked. By updating historyMessages every time a message is sent, new messages become immediately included in the chat history messages to load. This is not a problem if you reset the flow before loading chat history, but becomes an issue if you just load chat history after sending a few messages. You'll basically end up seeing the messages you just sent in the loaded chat history as well.

A possible fix is to simply ensure that when reset flow is called, we save the chat history at that moment before doing anything else. I'm currently not on my PC so this is what comes to mind - there may be cleaner solutions. If you're keen to continue exploring do let me know, otherwise I can take up this fix sometime as well 😊

@alexpeelman
Copy link
Author

I was looking into it further and indeed saw that my one line fix is not what we want 😅 . I totally agree with your suggestion to solve it when restartFlow is called and will take time today to explore that solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants