App "Generating" in the background at start when history is enabled, no issue if disabled
Francois2024 opened this issue · comments
Describe the bug
If I enable the history option, the app tries to generate content when the url is loaded when starting the app. This prevents the user from using the chatbot for 5-10 seconds. No content is generated in the end but there is a process running in the background which shows the app as being in content generation mode.
To Reproduce
Steps to reproduce the behavior:
- Load your app with history option enabled
- "Stop Generating" is active for 5-10 sec (eventhough no content has been entered in the chat window)
- Wait 5-10 sec and then user can start prompting the chatbot
Expected behavior
Same behaviour as when history is not enabled. No content generation attempt at start.
Screenshots
If applicable, add screenshots to help explain your problem.
Configuration: Please provide the following
- GPT4 Turbo (1106 preview)
- Chat history enabled
- No changes to the original repo (except for some visual css changes).
Additional context
Add any other context about the problem here.
There's no content actually being generated. In the first few seconds the app connects to the history database and reads your chats from there. Until these requests have completed, the application shows the "generating" hint. That's also the reason this behavior only occurs when history is enabled.
Thanks for the explanation. Is there a way to disable this behavior so it does not read the chats history? This is not useful for us and it creates a 5-10 seconds loading delay before the user can query the app.
Sort of, but not without some programming knowledge. We implemented lazy loading for chat messages in our fork, which helps to reduce the number of requests sent initially and therefore cuts down on loading time. However, if you want to keep the history feature, there's no sensible way around establishing a connection to the database initially. You can't save messages to the DB if there's no connection to the DB.
Ok got it thanks for your help. We will look into it.
We removed the history feature for now until we find a solution.
FWIW, our fork currently has 4.5s of loading time, but we're doing some additional requests as well, so implementing lazy loading for the chat messages would probably reduce the initial wait to 3-4s. Keep in mind that this is a very rough estimation influenced by a boatload of factors.
Ok! Thanks. This repo is by the way very useful as a starting point.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.