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]: No "create brain" options when running on WSL #2332

Closed
pachadotdev opened this issue Mar 9, 2024 · 6 comments
Closed

[Bug]: No "create brain" options when running on WSL #2332

pachadotdev opened this issue Mar 9, 2024 · 6 comments
Labels
area: frontend Related to frontend functionality or under the /frontend directory bug Something isn't working Stale

Comments

@pachadotdev
Copy link

What happened?

A bug happened! I installed Quivr from the main git branch on WSL (I couldn't get to install Scoop). It runs on localhost:3000, but when I click on "create a new brain", the displayed rectangle shows 0 options. What should I do? I added the OPENAI token as OPENAI_API_KEY=111222333, should it be OPENAI_API_KEY="111222333"? I already tried with quotes.

Relevant log output

No response

Twitter / LinkedIn details

No response

@pachadotdev pachadotdev added the bug Something isn't working label Mar 9, 2024
Copy link

dosubot bot commented Mar 9, 2024

Based on the context provided, it seems like you've encountered a similar issue to what others have faced in the past. Here are some steps you can take to resolve this issue:

  1. Update your frontend .env file to use your local IP: Change NEXT_PUBLIC_BACKEND_URL=localhost:5050 to NEXT_PUBLIC_BACKEND_URL=http://192.168.1.15:5050 (replace 192.168.1.15 with your local IP). Also, make sure to open port 5050 in your firewall.

  2. Setup Quivr for the first time: If you're setting up Quivr for the first time, follow these steps:

    • Clone the Quivr repository
    • Copy env.example to .env for both the frontend and backend
    • Populate the Supabase details in both files
    • Run docker compose up in VSCode
    • Once the container is running, copy the two tables mentioned in the issue and run them as queries in Supabase
    • Refresh localhost:3000
    • You should see "Default brain" in the dropdown and be able to create a new brain
  3. Fix Windows characters in start.sh: If you're using Windows, the issue might be due to the file start.sh being saved to git with Windows characters. You can fix this by running the command dos2unix backend/core/scripts/start.sh and restarting the docker compose.

These solutions are based on similar issues that have been resolved in the past. You can refer to these issues for more details:

If none of the above suggestions fix the problem you are facing, further investigation and more detailed logs might be required to resolve the issue. Please provide any error messages or logs you encounter during the process, as they can be very helpful in diagnosing the problem.

Sources

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

@pachadotdev pachadotdev changed the title [Bug]: [Bug]: No "create brain" options when running on WSL Mar 9, 2024
@dosubot dosubot bot added the area: frontend Related to frontend functionality or under the /frontend directory label Mar 9, 2024
@pachadotdev
Copy link
Author

@dosu-bot Hi! I implemented those and it didn't work. I used both the LAN local IP and WSL IP. The problem persists.

Copy link

dosubot bot commented Mar 9, 2024

Based on the context provided, it seems like you've already taken several steps to troubleshoot the issue. However, the problem persists. Here are some additional steps you can take to resolve the issue:

  1. Check Backend Connectivity: Ensure that the backend service that provides the list of options for creating a new brain is running and accessible. The frontend code does not directly show how it fetches the options for creating a new brain, but it's likely that it relies on a backend service. Verify that the backend service is up and that the frontend can communicate with it over the expected port.

  2. Review Environment Variables: Double-check the .env file in the frontend to ensure that all necessary environment variables are correctly set. This includes not just the OPENAI token but also any other variables that might affect connectivity or feature availability, such as backend service URLs or feature flags.

  3. Inspect the AddBrainModal Component: The AddBrainModal component is likely responsible for handling the creation of a new brain, including displaying the options. Review the implementation of AddBrainModal to ensure it correctly fetches and displays the options for creating a new brain. Look for any API calls to fetch the options and check if those API calls are successful.

  4. Check Session Management: The code snippet includes a session check that redirects to a login page if no session is found. Ensure that the session is correctly established and maintained. If the session is not correctly handled, it might prevent certain features or data from being accessible, including the options for creating a new brain.

  5. Review Network and Console Logs: Use the browser's developer tools to inspect network requests and console logs for any errors or failed requests. This can provide clues if there are issues with fetching data or other errors that might prevent the options from being displayed.

  6. Ensure Correct Component Mounting: Since the useEffect hook is used to check the session and potentially redirect users, ensure that all components, especially AddBrainModal, are correctly mounted and rendered. If there's an issue with component lifecycle or rendering logic, it might prevent the modal from displaying the options correctly.

  7. Backend Configuration and Data: Verify that the backend is correctly configured to serve the necessary data for creating a new brain. This includes checking database connections, API endpoints, and any relevant configuration that might affect data availability.

If after following these steps the issue persists, it might be helpful to provide more detailed logs or error messages that you're encountering. This could help in identifying the root cause of the issue.

Sources

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

@Croccodoyle
Copy link

duplicate of 2322

@pachadotdev
Copy link
Author

duplicate of 2322

hi @Croccodoyle , I do not really understand why it is a duplicate, I just configured Quivr folowing the tutorial

Copy link
Contributor

Thanks for your contributions, we'll be closing this issue as it has gone stale. Feel free to reopen if you'd like to continue the discussion.

@github-actions github-actions bot added the Stale label Jun 16, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: frontend Related to frontend functionality or under the /frontend directory bug Something isn't working Stale
Projects
None yet
Development

No branches or pull requests

2 participants