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

Mito AI: Restore chat on refresh #1488

Draft
wants to merge 12 commits into
base: dev
Choose a base branch
from
Draft

Mito AI: Restore chat on refresh #1488

wants to merge 12 commits into from

Conversation

ktaletsk
Copy link
Collaborator

Description

  • Keep the full history (prompts, display messages, metadata) in the backend.
  • Move backend storage from memory to the disk (JSON or sqlite).
  • Create new websocket message types to receive the history.
  • Restore history when the extension loads.

Testing

  1. Start a new chat or explain code or debug error
  2. Refresh the browser page or close and reopen JupyterLab page

Documentation

N/A

@ktaletsk ktaletsk requested a review from aarondr77 January 22, 2025 03:35
Copy link

vercel bot commented Jan 22, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
monorepo ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 23, 2025 7:33am

clear file when clearing history
Comment on lines +64 to +67
data = {
"llm_history": self._llm_history,
"display_history": self._display_history,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option here is to just store the metadata that we send from the frontend to the backend in order to create the prompt in the .json file. Then, we can easily recreate both the llm_history and the display_history from them. There's no reason for the backend to care about the display_messages for example.

What do you think about refactoring this? Is there an advantage to storing everything in the .json file itself?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for the backend to care about display_messages is to be able to restore them in the frontend when the extension loads.

I chose the format of what is stored in JSON to match what is stored in the memory, so it is easy to serialize/deserialize. That being said, we don't have to strore full text representations of either and can recalculate on the fly from context objects.

As I see it, there is no compeling reason to store that metadata, becuase the only thing we do with it is to calculate LLM prompts and display messages.

${input}`};
}

const removeInnerThoughtsFromMessage = (messageContent: string) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're going to need this sort of post-processing code in the frontend for when we stream responses to the frontend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants