langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-24 04:25:01 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

When an API requests a workflow and the workflow’s execution time exceeds 60 seconds, Dify automatically returns a 504 error. #15936

New Issue
Closed
opened 2026-02-21 19:24:02 -05:00 by yindo · 6 comments
yindo commented 2026-02-21 19:24:02 -05:00
Owner
Copy Link
Copy Source

Originally created by @Mxk-1 on GitHub (Aug 6, 2025).

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

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When an API requests a workflow and the workflow’s execution time exceeds 60 seconds, Dify automatically returns a 504 error.

✔️ Expected Behavior

We can afford to wait longer, but we must receive the response, because Dify’s API monitoring shows that the request parameters are being received correctly and the workflow executes normally.

❌ Actual Behavior

No response

Originally created by @Mxk-1 on GitHub (Aug 6, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.5.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce When an API requests a workflow and the workflow’s execution time exceeds 60 seconds, Dify automatically returns a 504 error. ### ✔️ Expected Behavior We can afford to wait longer, but we must receive the response, because Dify’s API monitoring shows that the request parameters are being received correctly and the workflow executes normally. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 19:24:02 -05:00
yindo closed this issue 2026-02-21 19:24:02 -05:00
yindo commented 2026-02-21 19:24:02 -05:00
Author
Owner
Copy Link
Copy Source

@Mxk-1 commented on GitHub (Aug 6, 2025):

@dosu

@Mxk-1 commented on GitHub (Aug 6, 2025): @dosu
yindo commented 2026-02-21 19:24:02 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 6, 2025):

The 60-second timeout and resulting 504 error in your self-hosted Dify setup are caused by default timeout settings in your Docker environment, not by Dify's internal workflow limits. To support longer-running workflows, increase these environment variables in your .env file and docker-compose.yaml: API_TOOL_DEFAULT_READ_TIMEOUT, CODE_EXECUTION_READ_TIMEOUT, and WORKFLOW_MAX_EXECUTION_TIME (for example, set them to 3600 for 1 hour). Then restart your Docker containers to apply the changes.

Also, check for hardcoded timeout values in the codebase (such as in api/core/model_runtime/model_providers/ollama/llm/llm.py) if you use specific providers, and make sure your Gunicorn and NGINX timeouts are not set lower than your desired limit. For long-running requests, consider using the 'streaming' response mode to avoid blocking timeouts. Be aware that increasing timeouts can raise resource usage, so monitor your system after making changes.
Reference 1 | Reference 2 | Reference 3

To reply, just mention @dosu.

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

@dosubot[bot] commented on GitHub (Aug 6, 2025): <!-- Answer --> The 60-second timeout and resulting 504 error in your self-hosted Dify setup are caused by default timeout settings in your Docker environment, not by Dify's internal workflow limits. To support longer-running workflows, increase these environment variables in your .env file and docker-compose.yaml: API_TOOL_DEFAULT_READ_TIMEOUT, CODE_EXECUTION_READ_TIMEOUT, and WORKFLOW_MAX_EXECUTION_TIME (for example, set them to 3600 for 1 hour). Then restart your Docker containers to apply the changes. Also, check for hardcoded timeout values in the codebase (such as in api/core/model_runtime/model_providers/ollama/llm/llm.py) if you use specific providers, and make sure your Gunicorn and NGINX timeouts are not set lower than your desired limit. For long-running requests, consider using the 'streaming' response mode to avoid blocking timeouts. Be aware that increasing timeouts can raise resource usage, so monitor your system after making changes. [Reference 1](https://github.com/langgenius/dify/issues/19173) | [Reference 2](https://github.com/langgenius/dify/issues/20274) | [Reference 3](https://github.com/langgenius/dify/issues/22196) <!-- 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/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/36115786-39c8-4266-b5a0-4ebb79ce9f2a?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&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/23502)
yindo commented 2026-02-21 19:24:02 -05:00
Author
Owner
Copy Link
Copy Source

@Mxk-1 commented on GitHub (Aug 6, 2025):

I have already run the relevant tests, but it had no effect; it still returns a 504 error.

@dosu

@Mxk-1 commented on GitHub (Aug 6, 2025): I have already run the relevant tests, but it had no effect; it still returns a 504 error. @dosu
yindo commented 2026-02-21 19:24:02 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 6, 2025):

If increasing the timeout environment variables had no effect and you still get a 504 after 60 seconds, it's likely the timeout is enforced by your infrastructure, not Dify itself. Here’s what to check next:

  1. Confirm if you’re using blocking or streaming response mode—streaming mode is much less prone to timeouts, especially with reverse proxies or load balancers source.
  2. Double-check your NGINX (or other reverse proxy) and Gunicorn timeout settings. In Docker setups, NGINX proxy timeouts (NGINX_PROXY_READ_TIMEOUT, NGINX_PROXY_SEND_TIMEOUT) and Gunicorn’s GUNICORN_TIMEOUT should be set much higher than 60 seconds (defaults are 3600s and 360s, respectively, in the example configs) source.
  3. Make sure you’ve set all relevant environment variables in your .env and docker-compose.yaml: API_TOOL_DEFAULT_READ_TIMEOUT, CODE_EXECUTION_READ_TIMEOUT, WORKFLOW_MAX_EXECUTION_TIME, APP_MAX_EXECUTION_TIME, HTTP_REQUEST_MAX_CONNECT_TIMEOUT, HTTP_REQUEST_MAX_READ_TIMEOUT, HTTP_REQUEST_MAX_WRITE_TIMEOUT, and SSRF timeouts. All must be set to a high value (e.g., 3600) source.
  4. If you use Ollama or other model providers, check for hardcoded timeouts in the code (e.g., timeout=(10, 300) in api/core/model_runtime/model_providers/ollama/llm/llm.py) and increase them if needed source.
  5. After any change, fully rebuild and restart all containers to ensure new settings are loaded.
  6. If the problem persists, check logs from Dify, NGINX, and Gunicorn at the time of the error to pinpoint which layer triggers the 504.

If you share your current .env and docker-compose.yaml timeout settings, and details about your reverse proxy setup, I can help spot anything missing.

To reply, just mention @dosu.

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

@dosubot[bot] commented on GitHub (Aug 6, 2025): <!-- Answer --> If increasing the timeout environment variables had no effect and you still get a 504 after 60 seconds, it's likely the timeout is enforced by your infrastructure, not Dify itself. Here’s what to check next: 1. Confirm if you’re using blocking or streaming response mode—streaming mode is much less prone to timeouts, especially with reverse proxies or load balancers [source](https://github.com/langgenius/dify/issues/15728). 2. Double-check your NGINX (or other reverse proxy) and Gunicorn timeout settings. In Docker setups, NGINX proxy timeouts (NGINX_PROXY_READ_TIMEOUT, NGINX_PROXY_SEND_TIMEOUT) and Gunicorn’s GUNICORN_TIMEOUT should be set much higher than 60 seconds (defaults are 3600s and 360s, respectively, in the example configs) [source](https://github.com/langgenius/dify/blob/c95761f4e6234a27a31446bec768da72826d3324/docker/.env.example). 3. Make sure you’ve set all relevant environment variables in your .env and docker-compose.yaml: API_TOOL_DEFAULT_READ_TIMEOUT, CODE_EXECUTION_READ_TIMEOUT, WORKFLOW_MAX_EXECUTION_TIME, APP_MAX_EXECUTION_TIME, HTTP_REQUEST_MAX_CONNECT_TIMEOUT, HTTP_REQUEST_MAX_READ_TIMEOUT, HTTP_REQUEST_MAX_WRITE_TIMEOUT, and SSRF timeouts. All must be set to a high value (e.g., 3600) [source](https://github.com/langgenius/dify/issues/19173). 4. If you use Ollama or other model providers, check for hardcoded timeouts in the code (e.g., timeout=(10, 300) in api/core/model_runtime/model_providers/ollama/llm/llm.py) and increase them if needed [source](https://github.com/langgenius/dify/issues/19173). 5. After any change, fully rebuild and restart all containers to ensure new settings are loaded. 6. If the problem persists, check logs from Dify, NGINX, and Gunicorn at the time of the error to pinpoint which layer triggers the 504. If you share your current .env and docker-compose.yaml timeout settings, and details about your reverse proxy setup, I can help spot anything missing. <!-- 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/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/6f5747c4-2c5a-451b-a908-3f6927076842?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&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/23502)
yindo commented 2026-02-21 19:24:02 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Aug 6, 2025):

I there there is something wrong with your Nginx settings. The error code 504 is usually returned by Nginx.

I suggest you read this thread instead https://stackoverflow.com/questions/24453388/nginx-reverse-proxy-causing-504-gateway-timeout

We can not reproduce this error from our side.

When an API requests a workflow and the workflow’s execution time exceeds 60 seconds, Dify automatically returns a 504 error.

Also it's hard to guess what's happening from a single sentence.

Please read Contributing Guide as well.

@crazywoola commented on GitHub (Aug 6, 2025): I there there is something wrong with your Nginx settings. The error code `504` is usually returned by Nginx. I suggest you read this thread instead https://stackoverflow.com/questions/24453388/nginx-reverse-proxy-causing-504-gateway-timeout We can not reproduce this error from our side. > When an API requests a workflow and the workflow’s execution time exceeds 60 seconds, Dify automatically returns a 504 error. Also it's hard to guess what's happening from a single sentence. Please read [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md#bug-reports) as well.
yindo commented 2026-02-21 19:24:03 -05:00
Author
Owner
Copy Link
Copy Source

@SomaLily commented on GitHub (Aug 7, 2025):

may set
NGINX_KEEPALIVE_TIMEOUT=300
API_TOOL_DEFAULT_CONNECT_TIMEOUT=300
API_TOOL_DEFAULT_READ_TIMEOUT=300

@SomaLily commented on GitHub (Aug 7, 2025): may set NGINX_KEEPALIVE_TIMEOUT=300 API_TOOL_DEFAULT_CONNECT_TIMEOUT=300 API_TOOL_DEFAULT_READ_TIMEOUT=300
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15936
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?