🐛 Bug Report: Empty list of available documentation when VITE_API_HOST is not defined

[starkgate]

📜 Description

The list of available documentation fails to load when VITE_API_HOST is not defined.

👟 Reproduction steps

Running DocsGPT 0.9.0 on a Linux machine with ./setup.sh and choosing the second option (use local model), I see the following error when opening the frontend and trying to select documentation: No default documentation

👍 Expected behavior

After digging around, I located the issue in frontend/src/preferences/preferenceApi.ts: the URL the list is fetched from (https://docsapi.arc53.com) seems to be down. Replacing the URL with https://d3dg1063dc54p9.cloudfront.net/combined.json works.

👎 Actual Behavior with Screenshots

💻 Operating system

Linux

What browsers are you seeing the problem on?

Firefox, Chrome

🤖 What development environment are you experiencing this bug on?

Docker

🔒 Did you set the correct environment variables in the right path? List the environment variable names (not values please!)

LLM_NAME
VITE_API_STREAMING
EMBEDDINGS_NAME

📃 Provide any additional context for the Bug.

I believe this is related to #301, however the errors in the log discussed in that issue differ from what I observed.

📖 Relevant log output

The application is now running on http://localhost:5173
You can stop the application by running the following command:
Ctrl + C and then
Then pkill -f 'flask run' and then
docker-compose down
 * Serving Flask app 'application/app.py'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:7091
 * Running on http://192.168.2.74:7091
Press CTRL+C to quit
 * Restarting with stat

 -------------- celery@sunspear-vm v5.3.6 (emerald-rush)
--- ***** -----
-- ******* ---- Linux-5.15.0-102-generic-x86_64-with-glibc2.35 2024-05-02 09:24:02
- *** --- * ---
- ** ---------- [config]
- ** ---------- .> app:         application.celery:0x7fcbb19df5e0
- ** ---------- .> transport:   redis://localhost:6379/0
- ** ---------- .> results:     redis://localhost:6379/1
- *** --- * --- .> concurrency: 16 (prefork)
-- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
--- ***** -----
 -------------- [queues]
                .> celery           exchange=celery(direct) key=celery


[tasks]
  . application.api.user.tasks.ingest
  . application.api.user.tasks.ingest_remote

[2024-05-02 09:24:07,322: WARNING/MainProcess] /home/jstark/.local/lib/python3.10/site-packages/celery/worker/consumer/consumer.py:507: CPendingDeprecationWarning: The broker_connection_retry configuration setting will no longer determine
whether broker connection retries are made during startup in Celery 6.0 and above.
If you wish to retain the existing behavior for retrying connections on startup,
you should set broker_connection_retry_on_startup to True.
  warnings.warn(

[2024-05-02 09:24:07,331: INFO/MainProcess] Connected to redis://localhost:6379/0
[2024-05-02 09:24:07,331: WARNING/MainProcess] /home/jstark/.local/lib/python3.10/site-packages/celery/worker/consumer/consumer.py:507: CPendingDeprecationWarning: The broker_connection_retry configuration setting will no longer determine
whether broker connection retries are made during startup in Celery 6.0 and above.
If you wish to retain the existing behavior for retrying connections on startup,
you should set broker_connection_retry_on_startup to True.
  warnings.warn(

[2024-05-02 09:24:07,334: INFO/MainProcess] mingle: searching for neighbors
[2024-05-02 09:24:08,344: INFO/MainProcess] mingle: all alone
[2024-05-02 09:24:08,358: INFO/MainProcess] celery@sunspear-vm ready.
 * Debugger is active!
 * Debugger PIN: 934-945-286

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

🔗 Are you willing to submit PR?

None

🧑‍⚖️ Code of Conduct

• I agree to follow this project's Code of Conduct

[starkgate]

Investigating a bit further, the actual cause of my problem seems to be that I am accessing the DocsGPT UI from a separate machine. Modifying VITE_API_HOST to the host machine's IP address instead of localhost in docker-compose-local.yaml works as well, without having to change any code.

More than a bug, I guess this is something that should be added to the documentation. Unless I missed something, I didn't see any instructions related to this kind of use case.

[Fagner-lourenco]

have the same problem after the last update