Page loading failed after calling API #15282

Closed
opened 2026-02-21 19:21:01 -05:00 by yindo · 6 comments
Owner

Originally created by @lixc123 on GitHub (Jul 11, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.5.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Calling dify's send messages (/chat messages) interface through the API will timeout, and the web page will not open and keep loading. Restarting Docker will work normally, or it may take a few minutes to recover

✔️ Expected Behavior

No response

Actual Behavior

Image
Originally created by @lixc123 on GitHub (Jul 11, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.5.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Calling dify's send messages (/chat messages) interface through the API will timeout, and the web page will not open and keep loading. Restarting Docker will work normally, or it may take a few minutes to recover ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior <img width="853" height="511" alt="Image" src="https://github.com/user-attachments/assets/2b6acd59-cc60-44a8-a7f0-6c5602e561a8" />
yindo added the 🐞 bug🤔 cant-reproduce labels 2026-02-21 19:21:01 -05:00
yindo closed this issue 2026-02-21 19:21:01 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Jul 11, 2025):

This kind of timeout and infinite loading is often caused by resource exhaustion or bottlenecks in the backend—like database connection pool limits, thread exhaustion, or slow responses from external services (LLM APIs, vector DBs, or dataset retrieval). When these resources are maxed out, the API can hang, and the frontend will keep loading until the backend recovers or is restarted. Restarting Docker resets these pools, which matches your observation that things work again after a restart.

Here’s what you can do to troubleshoot and mitigate:

  • Check your Docker and backend logs when the issue happens—look for errors, warnings, or signs of resource exhaustion (e.g., “too many connections”, “thread pool exhausted”, or stack traces).
  • Monitor your server’s CPU, RAM, and disk usage, as well as database connection counts, when the problem occurs.
  • Make sure your Docker containers have enough resources allocated. If you’re running with default limits, try increasing CPU/memory for the backend and database containers.
  • If you use external LLM APIs or vector databases, check their health and response times. Slow or failing external calls can block the whole pipeline.
  • Review your Dify rate limits and cooldown settings—if you hit these, requests may hang until the cooldown expires.
  • If you have a high number of concurrent users or requests, consider scaling up your deployment or tuning connection/thread pool sizes.

Recent pull requests have fixed some internal server errors and variable handling issues in advanced chat workflows, so if you’re able, consider testing with a newer Dify version to see if the problem persists (PR 20614, PR 21604).

If the issue keeps happening, sharing relevant log snippets or resource metrics from the time of failure will help pinpoint the root cause.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 11, 2025): <!-- Answer --> This kind of timeout and infinite loading is often caused by resource exhaustion or bottlenecks in the backend—like database connection pool limits, thread exhaustion, or slow responses from external services (LLM APIs, vector DBs, or dataset retrieval). When these resources are maxed out, the API can hang, and the frontend will keep loading until the backend recovers or is restarted. Restarting Docker resets these pools, which matches your observation that things work again after a restart. Here’s what you can do to troubleshoot and mitigate: - Check your Docker and backend logs when the issue happens—look for errors, warnings, or signs of resource exhaustion (e.g., “too many connections”, “thread pool exhausted”, or stack traces). - Monitor your server’s CPU, RAM, and disk usage, as well as database connection counts, when the problem occurs. - Make sure your Docker containers have enough resources allocated. If you’re running with default limits, try increasing CPU/memory for the backend and database containers. - If you use external LLM APIs or vector databases, check their health and response times. Slow or failing external calls can block the whole pipeline. - Review your Dify rate limits and cooldown settings—if you hit these, requests may hang until the cooldown expires. - If you have a high number of concurrent users or requests, consider scaling up your deployment or tuning connection/thread pool sizes. Recent pull requests have fixed some internal server errors and variable handling issues in advanced chat workflows, so if you’re able, consider testing with a newer Dify version to see if the problem persists ([PR 20614](https://github.com/langgenius/dify/pull/20614), [PR 21604](https://github.com/langgenius/dify/pull/21604)). If the issue keeps happening, sharing relevant log snippets or resource metrics from the time of failure will help pinpoint the root cause. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c79f7e0f-d6b6-4864-8245-010c11f8f2f7?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/22234)
Author
Owner

@crazywoola commented on GitHub (Jul 11, 2025):

Please provide some logs or steps to reproduce.

@crazywoola commented on GitHub (Jul 11, 2025): Please provide some logs or steps to reproduce.
Author
Owner

@souravnex commented on GitHub (Jul 11, 2025):

Hey, I'm also facing this same issue. I have just deployed and changed the port of nginx directly in the Docker Compose file, and forwarded it to my nginx with a subdomain, but I am getting this error

Image Image Image
@souravnex commented on GitHub (Jul 11, 2025): Hey, I'm also facing this same issue. I have just deployed and changed the port of nginx directly in the Docker Compose file, and forwarded it to my nginx with a subdomain, but I am getting this error <img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/407af0c7-2f2f-4c65-b6af-7da13aaf5f68" /> <img width="1852" height="717" alt="Image" src="https://github.com/user-attachments/assets/027a5082-fada-4df2-a2b2-032f09c3f0a3" /> <img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/e7152661-9fbc-453e-b1ec-a374c0beae3f" />
Author
Owner

@crazywoola commented on GitHub (Jul 11, 2025):

It seems that you have a problem when you connecting the database, please check your environment settings and networks between each container. I suggest you sync the changes of the .env between each version. @souravnex

@crazywoola commented on GitHub (Jul 11, 2025): It seems that you have a problem when you connecting the database, please check your environment settings and networks between each container. I suggest you sync the changes of the `.env` between each version. @souravnex
Author
Owner

@souravnex commented on GitHub (Jul 11, 2025):

Hey @crazywoola

i have changed on .env, but it is not working

Image Image

When I changed on compose file
ports:

  • "10001:80"
  • "10000:443"

It has the problem that I shared previously

@souravnex commented on GitHub (Jul 11, 2025): Hey @crazywoola i have changed on .env, but it is not working <img width="1391" height="497" alt="Image" src="https://github.com/user-attachments/assets/613d826b-bf5e-49eb-96cf-ae21ebad7ee1" /> <img width="1911" height="376" alt="Image" src="https://github.com/user-attachments/assets/cbc6ec30-c632-4385-9d62-3e2e0456560c" /> When I changed on compose file ports: - "10001:80" - "10000:443" It has the problem that I shared previously
Author
Owner

@lixc123 commented on GitHub (Jul 12, 2025):

Solved by adjusting the number of server worker amount in env

@lixc123 commented on GitHub (Jul 12, 2025): Solved by adjusting the number of server worker amount in env
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15282