[Bug]: When the agent is running, other requests are not responded to.

[TeslaZY]

Self Checks

• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (Language Policy).
• [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• [x] Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

2fd5ac10

RAGFlow image version

No System page now

Other environment information

- M4 max
- macOS

Actual behavior

When running an agent, other requests will be blocked. The front-end interface of the whole ragflow does not respond.

Expected behavior

No response

Steps to reproduce

1. Open two ragflow pages, one is agent, and the other is any page, and run agent on the agent interface.
2. Do anything on the other page
3. There is no response to another page request.

Additional information

[dosubot[bot]]

Agent execution in RAGFlow uses async Server-Sent Events (SSE) and a ThreadPoolExecutor to run components concurrently, which should allow multiple requests to be handled at once if the backend is configured for concurrency. However, blocking can still happen if the server is running with only a single worker or if any agent component performs CPU-bound or long-running synchronous operations that monopolize the Python GIL or event loop. This would prevent other requests from being processed, making the UI unresponsive even though the code is designed for async streaming and concurrency (canvas_app.py, canvas.py).

Check how your backend server is deployed—make sure it's running with multiple workers (for example, using Gunicorn or Uvicorn with several worker processes if using an ASGI server). Also, review any custom agent components for blocking code, and consider offloading heavy or synchronous tasks to background jobs or separate processes if needed. Monitoring server logs and resource usage during agent runs can help pinpoint bottlenecks. Recent code changes have improved concurrency, but the root cause of blocking is likely related to deployment configuration or CPU-bound code in components, not the async/SSE architecture itself (PR #11016, PR #10766).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[VinncentZHZ]

The same blocking issue was observed in RAGFlow v0.22.0, whereas it did not occur under the same agent configuration in RAGFlow v0.21.0.

[TeslaZY]

Use commit：221947ac, the problem still occurs.