Dify 1.16.1 - Infinite "Syncing Data" State Related to Collaboration/WebSocket Subsystem

Self Checks

• I have read the Contributing Guide and Language Policy.
• 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, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.16.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Author Note

This report was prepared with the assistance of Microsoft M365 Copilot after a complete end-to-end troubleshooting session. The issue was investigated through multiple diagnostic stages including Docker analysis, Redis validation, PostgreSQL verification, WebSocket troubleshooting, Nginx inspection, browser developer tools analysis, environment configuration review, and comparison against existing Dify GitHub issues.

The investigation required several hours of systematic troubleshooting and iterative testing. During the process, infrastructure, networking, database, Redis, Docker, Nginx, and application-layer causes were progressively eliminated before isolating the Collaboration/WebSocket subsystem as the most likely source of the problem. The workaround described below was tested and successfully validated.

Environment

• Dify 1.16.1
• Self-Hosted Docker Deployment
• Windows + Docker Desktop
• PostgreSQL
• Redis
• Weaviate

Problem Description

Application creation and workflow loading remained indefinitely stuck on:

Syncing Data...

The issue persisted even after completely rebuilding the Docker environment.

Symptoms

Browser Console:

WebSocket connection rejected by server

AbortError: signal is aborted without reason

docker-api_websocket-1 logs:

Cannot receive from redis... retrying in 1 secs

Observed Behavior

• All core containers were running successfully.
• PostgreSQL was healthy.
• Redis was healthy.
• API was healthy.
• Docker networking was functioning normally.
• Redis DNS resolution worked correctly.
• Redis TCP connectivity worked correctly.
• Redis authentication worked correctly.
• Nginx routing appeared correct.
• All Network requests returned HTTP 200.
• No database errors were observed.
• No Nginx errors were observed.

Investigation Findings

The only service consistently reporting errors was:

docker-api_websocket-1

which continuously logged:

Cannot receive from redis... retrying in 1 secs

At the same time, the browser consistently reported:

WebSocket connection rejected by server

This suggested that the issue was related to the Collaboration/WebSocket subsystem rather than the core API, database, Redis service, or Docker networking.

Related GitHub Issue

A similar issue appears to be described in:

#39423
socket_timeout on the Socket.IO pub/sub connection makes workflow collaboration impossible

The symptoms appear closely related, particularly the repeated:

Cannot receive from redis... retrying in 1 secs

message originating from the WebSocket service.

Workaround Applied

The following setting was changed:

Before:

ENABLE_COLLABORATION_MODE=true

After:

ENABLE_COLLABORATION_MODE=false

Then:

docker compose down
docker compose up -d

Result

After disabling Collaboration Mode:

• Application creation worked normally.
• Workflow loading completed successfully.
• Synchronization completed successfully.
• The infinite "Syncing Data..." state disappeared.
• WebSocket errors disappeared.
• Dify became fully operational.

Conclusion

The issue does not appear to be caused by:

• PostgreSQL
• Redis availability
• Docker networking
• Nginx routing
• General API functionality

Based on the investigation, the most likely source of the problem is the Collaboration/WebSocket subsystem in Dify 1.16.x.

Disabling Collaboration Mode provided a reliable workaround and immediately restored normal platform operation.

Any feedback from the maintainers would be greatly appreciated.

✔️ Expected Behavior

Dify should complete application creation and workflow loading successfully without remaining stuck on "Syncing Data".

The Collaboration/WebSocket service should establish a stable connection to Redis Pub/Sub without repeatedly logging:

"Cannot receive from redis... retrying in 1 secs"

and without rejecting WebSocket connections from the browser.

Workflow synchronization should complete normally while Collaboration Mode is enabled.

❌ Actual Behavior

The UI remains indefinitely stuck on "Syncing Data".

Browser Console reports:

"WebSocket connection rejected by server"

and docker-api_websocket-1 continuously logs:

"Cannot receive from redis... retrying in 1 secs"

The issue disappears after changing:

ENABLE_COLLABORATION_MODE=true

to:

ENABLE_COLLABORATION_MODE=false

[dosubot]

Hi @faisal703870-dev! I'm Dosu and I'm helping the Dify team.

Great investigation — your findings align with two confirmed bugs in the 1.16.x collaboration/WebSocket subsystem that are actively being tracked.

Root cause: socket_timeout on the Socket.IO pub/sub listener. The _build_redis_options() function in ext_socketio.py passes socket_timeout (default 5s) into socketio.RedisManager, which runs a blocking pubsub.listen() loop. After ~5s of silence, the read raises TimeoutError, python-socketio catches it, logs "Cannot receive from redis... retrying in 1 secs", resubscribes, and repeats forever — so events are never delivered. This was reported and root-caused in #39423 [1]. The fix has not yet been merged into main — socket_timeout is still being passed to the RedisManager [2].

There's also a SECRET_KEY mismatch issue. The api_websocket container is missing the shared storage volume mount that api and worker have. When SECRET_KEY is empty (the default), each container auto-generates its own key into its own storage directory, causing JWT verification failures (InvalidSignatureError) on every WebSocket connection. This was filed as #39422 with a fix in PR #39424, which is still open [3].

Your workaround of ENABLE_COLLABORATION_MODE=false is correct and is the simplest way to restore normal operation until these fixes land.

If you want to keep collaboration mode enabled while waiting, you can also try:

• Setting REDIS_SOCKET_TIMEOUT=0 in your .env to disable the timeout globally (this works around the pub/sub issue but affects all Redis clients)
• Setting an explicit SECRET_KEY value in your .env so both api and api_websocket use the same key (works around the JWT mismatch)

Multiple other users are experiencing the same issue on 1.16.x — see #39694 for another report with similar symptoms [4]. A maintainer has also pointed to the collaboration configuration docs which may help with proper setup [4].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.