Long-running conversation workflow frontend output disappears, but backend still running (adjusted timeout parameters not working)

[qindong76]

Self Checks

• 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.

Content

Title
Long-running conversation workflow frontend output disappears, but backend still running (adjusted timeout parameters not working)
Body
When running a long-time conversation workflow (about 10 minutes), the frontend output suddenly disappears and returns to the initial conversation page, but the workflow is still executing in the backend normally.
I have already adjusted the following timeout parameters in .env and docker-compose.yaml and restarted the service, but the issue still persists:
plaintext
TEXT_GENERATION_TIMEOUT_MS=1200000
GUNICORN_TIMEOUT=1800
WORKFLOW_MAX_EXECUTION_TIME=1800
MODEL_REQUEST_TIMEOUT=1800
PLUGIN_DAEMON_TIMEOUT=1800
Environment
Dify version: 1.14.1
Deployment: Docker Compose
Browser: Chrome / Edge
Behavior
Start a long-running conversation workflow in the chat page
After a few minutes (even with continuous output), frontend output disappears
Frontend automatically returns to the new conversation page
Backend workflow continues to run and completes successfully
Questions
Is this a bug or expected behavior?
Why do the timeout parameters not prevent frontend disconnection?
Is there any official solution to keep the connection alive when the tab is in the background or idle?
Thank you.

[dosubot[bot]]

This is a known issue affecting Dify versions v1.8.1 through v1.14.x. The timeout parameters you've configured are correct but they're not the root cause of the frontend disconnection — Dify's default nginx timeouts are already set to 1 hour (3600s) [1], so your adjustments should have been sufficient from a timeout perspective.

The actual root cause is a race condition in Dify's SSE (Server-Sent Events) architecture involving Redis Pub/Sub. Events published by Celery workers can be lost if they arrive before the API server completes its Redis subscription, causing the frontend to lose its connection and reset to the initial conversation page — while the backend continues running normally [2].

Workarounds to try:

1. Increase the SSE fallback timeout — add this to your .env:

   SSE_TASK_START_FALLBACK_MS=30000
   

   This gives the API server more time to subscribe before task execution begins [3].

2. Ensure nginx has proper SSE configuration (check your nginx config includes):

   proxy_http_version 1.1;
   proxy_set_header Connection "";
   proxy_buffering off;
   proxy_cache off;

   Missing proxy_buffering off can cause streaming responses to buffer and trigger connection resets [4].

3. Scale your workers to reduce contention:

   CELERY_AUTO_SCALE=true
   CELERY_MAX_WORKERS=15
   CELERY_MIN_WORKERS=5
   SERVER_WORKER_AMOUNT=4
   

   [5]

4. Check the SSRF proxy (Squid) — older versions had hardcoded 120-second timeouts. If you're on v1.14.1, you can set SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT environment variables, or use NO_PROXY to bypass it for trusted backends [6].

To answer your questions directly:

• This is a bug, not expected behavior.
• The timeout parameters don't prevent it because the disconnection is caused by lost SSE events (a race condition), not a timeout expiring.
• There is no official keep-alive solution yet for background tabs, though a long-term fix via async response mode (decoupling workflow execution from connection lifetime) is being developed in PR #35301 [7].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.