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

Workflow failed to return file for download #21366

New Issue
Closed
opened 2026-02-21 20:12:12 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 20:12:12 -05:00
Owner
Copy Link
Copy Source

Originally created by @nosee818 on GitHub (Dec 30, 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.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Problem Description:

I generate videos using local deployed model , which typically takes around 15 minutes. While the workflow functions properly during internal testing, it fails to return results correctly when executed via a standalone webpage (likely due to time-related configuration issues).

I have reviewed and adjusted all timeout settings to ensure they exceed 15 minutes. The backend confirms successful execution ("Success" status), and I can verify the newly generated video file exists in the server directory. All workflows operate normally under standard conditions.

However, for shorter videos or images (which require significantly less time to process), the download file is provided correctly.

Image Image

✔️ Expected Behavior

My workflow can normally return video files in the web app page.

❌ Actual Behavior

No response

Originally created by @nosee818 on GitHub (Dec 30, 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.11.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Problem Description: I generate videos using local deployed model , which typically takes around 15 minutes. While the workflow functions properly during internal testing, it fails to return results correctly when executed via a standalone webpage (likely due to time-related configuration issues). I have reviewed and adjusted all timeout settings to ensure they exceed 15 minutes. The backend confirms successful execution ("Success" status), and I can verify the newly generated video file exists in the server directory. All workflows operate normally under standard conditions. However, for shorter videos or images (which require significantly less time to process), the download file is provided correctly. <img width="2864" height="1588" alt="Image" src="https://github.com/user-attachments/assets/5929cfe3-e690-4234-bbc4-a5386aaa3a41" /> <img width="2864" height="1588" alt="Image" src="https://github.com/user-attachments/assets/9f3b0d24-e611-40d5-8c37-ef5352aa882f" /> ### ✔️ Expected Behavior My workflow can normally return video files in the web app page. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:12:12 -05:00
yindo closed this issue 2026-02-21 20:12:12 -05:00
yindo commented 2026-02-21 20:12:12 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 30, 2025):

Hi @nosee818! I'm Dosu and I’m helping the dify team.

Your issue is almost certainly caused by frontend or proxy timeouts that interrupt the connection before the long-running workflow completes, even though the backend finishes and the file is saved. In Dify, the frontend timeout is controlled by the TEXT_GENERATION_TIMEOUT_MS setting (default 60s). If your workflow takes longer, the UI will timeout and fail to fetch the output file, even if the backend succeeds. You should set TEXT_GENERATION_TIMEOUT_MS in your .env to a value at least as long as your expected workflow duration, and make sure it matches or exceeds WORKFLOW_MAX_EXECUTION_TIME, GUNICORN_TIMEOUT, and NGINX proxy timeouts. All these must be set high enough to support your longest workflows. See details here.

Also, for self-hosted Docker setups, you need to set NGINX_PROXY_READ_TIMEOUT and NGINX_PROXY_SEND_TIMEOUT to high values (e.g., 1200 or more) in your environment and ensure these are reflected in your nginx config. A 404 or 504 after a long wait is usually due to nginx or an external proxy terminating the request, not the Dify backend. Double-check your nginx config for proxy_read_timeout, proxy_send_timeout, and any error_page or proxy_intercept_errors directives that might rewrite upstream errors to 404 or 504. More info here and here.

After changing these settings, fully rebuild and restart all containers to apply the new configuration. If you use specific model providers (like Ollama), check for hardcoded timeouts in their code as well.

Finally, Dify's file download mechanism uses signed URLs that expire after a configurable timeout (FILES_ACCESS_TIMEOUT). If the frontend or session times out, the UI may lose state and fail to fetch output attachments, even if the backend completed the workflow. Make sure all session/cache TTLs and proxy timeouts are set high enough, and avoid letting the browser idle or switching tabs during long runs.

If you still have issues after these changes, check nginx and application logs at the time of the error to pinpoint which layer is causing the timeout.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 30, 2025): <!-- Greeting --> Hi @nosee818! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> Your issue is almost certainly caused by frontend or proxy timeouts that interrupt the connection before the long-running workflow completes, even though the backend finishes and the file is saved. In Dify, the frontend timeout is controlled by the `TEXT_GENERATION_TIMEOUT_MS` setting (default 60s). If your workflow takes longer, the UI will timeout and fail to fetch the output file, even if the backend succeeds. You should set `TEXT_GENERATION_TIMEOUT_MS` in your `.env` to a value at least as long as your expected workflow duration, and make sure it matches or exceeds `WORKFLOW_MAX_EXECUTION_TIME`, `GUNICORN_TIMEOUT`, and NGINX proxy timeouts. All these must be set high enough to support your longest workflows. See details [here](https://github.com/langgenius/dify/issues/28279#issuecomment-3540406109). Also, for self-hosted Docker setups, you need to set `NGINX_PROXY_READ_TIMEOUT` and `NGINX_PROXY_SEND_TIMEOUT` to high values (e.g., 1200 or more) in your environment and ensure these are reflected in your nginx config. A 404 or 504 after a long wait is usually due to nginx or an external proxy terminating the request, not the Dify backend. Double-check your nginx config for `proxy_read_timeout`, `proxy_send_timeout`, and any error_page or proxy_intercept_errors directives that might rewrite upstream errors to 404 or 504. More info [here](https://github.com/langgenius/dify/issues/23916#issuecomment-3187113652) and [here](https://github.com/langgenius/dify/issues/23502). After changing these settings, fully rebuild and restart all containers to apply the new configuration. If you use specific model providers (like Ollama), check for hardcoded timeouts in their code as well. Finally, Dify's file download mechanism uses signed URLs that expire after a configurable timeout (`FILES_ACCESS_TIMEOUT`). If the frontend or session times out, the UI may lose state and fail to fetch output attachments, even if the backend completed the workflow. Make sure all session/cache TTLs and proxy timeouts are set high enough, and avoid letting the browser idle or switching tabs during long runs. If you still have issues after these changes, check nginx and application logs at the time of the error to pinpoint which layer is causing the timeout. <!-- 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/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Your%20issue%20is%20almost%20certainly%20caused%20by%20frontend%20or%20proxy%20timeouts%20that%20interrupt%20the%20connection%20before%20the%20long-running%20workflow%20completes%2C%20even%20though%20the%20backend%20finishes%20and%20the%20file%20is%20saved.%20In%20Dify%2C%20the%20frontend%20timeout%20is%20controlled%20by%20the%20%60TEXT_GENERATION_TIMEOUT_MS%60%20setting%20%28default%2060s%29.%20If%20your%20workflow%20takes%20longer%2C%20the%20UI%20will%20timeout%20and%20fail%20to%20fetch%20the%20output%20file%2C%20even%20if%20the%20backend%20succeeds.%20You%20should%20set%20%60TEXT_GENERATION_TIMEOUT_MS%60%20in%20your%20%60.env%60%20to%20a%20value%20at%20least%20as%20long%20as%20your%20expected%20workflow%20duration%2C%20and%20make%20sure%20it%20matches%20or%20exceeds%20%60WORKFLOW_MAX_EXECUTION_TIME%60%2C%20%60GUNICORN_TIMEOUT%60%2C%20and%20NGINX%20proxy%20timeouts.%20All%20these%20must%20be%20set%20high%20enough%20to%20support%20your%20longest%20workflows.%20See%20details%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/28279%23issuecomment-3540406109%29.%0A%0AAlso%2C%20for%20self-hosted%20Docker%20setups%2C%20you%20need%20to%20set%20%60NGINX_PROXY_READ_TIMEOUT%60%20and%20%60NGINX_PROXY_SEND_TIMEOUT%60%20to%20high%20values%20%28e.g.%2C%201200%20or%20more%29%20in%20your%20environment%20and%20ensure%20these%20are%20reflected%20in%20your%20nginx%20config.%20A%20404%20or%20504%20after%20a%20long%20wait%20is%20usually%20due%20to%20nginx%20or%20an%20external%20proxy%20terminating%20the%20request%2C%20not%20the%20Dify%20backend.%20Double-check%20your%20nginx%20config%20for%20%60proxy_read_timeout%60%2C%20%60proxy_send_timeout%60%2C%20and%20any%20error_page%20or%20proxy_intercept_errors%20directives%20that%20might%20rewrite%20upstream%20errors%20to%20404%20or%20504.%20More%20info%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/23916%23issuecomment-3187113652%29%20and%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/23502%29.%0A%0AAfter%20changing%20these%20settings%2C%20fully%20rebuild%20and%20restart%20all%20containers%20to%20apply%20the%20new%20configuration.%20If%20you%20use%20specific%20model%20providers%20%28like%20Ollama%29%2C%20check%20for%20hardcoded%20timeouts%20in%20their%20code%20as%20well.%0A%0AFinally%2C%20Dify%27s%20file%20download%20mechanism%20uses%20signed%20URLs%20that%20expire%20after%20a%20configurable%20timeout%20%28%60FILES_ACCESS_TIMEOUT%60%29.%20If%20the%20frontend%20or%20session%20times%20out%2C%20the%20UI%20may%20lose%20state%20and%20fail%20to%20fetch%20output%20attachments%2C%20even%20if%20the%20backend%20completed%20the%20workflow.%20Make%20sure%20all%20session/cache%20TTLs%20and%20proxy%20timeouts%20are%20set%20high%20enough%2C%20and%20avoid%20letting%20the%20browser%20idle%20or%20switching%20tabs%20during%20long%20runs.%0A%0AIf%20you%20still%20have%20issues%20after%20these%20changes%2C%20check%20nginx%20and%20application%20logs%20at%20the%20time%20of%20the%20error%20to%20pinpoint%20which%20layer%20is%20causing%20the%20timeout.)&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/30373)
yindo commented 2026-02-21 20:12:12 -05:00
Author
Owner
Copy Link
Copy Source

@nosee818 commented on GitHub (Dec 30, 2025):

Hi @nosee818! I'm Dosu and I’m helping the dify team.

Your issue is almost certainly caused by frontend or proxy timeouts that interrupt the connection before the long-running workflow completes, even though the backend finishes and the file is saved. In Dify, the frontend timeout is controlled by the TEXT_GENERATION_TIMEOUT_MS setting (default 60s). If your workflow takes longer, the UI will timeout and fail to fetch the output file, even if the backend succeeds. You should set TEXT_GENERATION_TIMEOUT_MS in your .env to a value at least as long as your expected workflow duration, and make sure it matches or exceeds WORKFLOW_MAX_EXECUTION_TIME, GUNICORN_TIMEOUT, and NGINX proxy timeouts. All these must be set high enough to support your longest workflows. See details here.

Also, for self-hosted Docker setups, you need to set NGINX_PROXY_READ_TIMEOUT and NGINX_PROXY_SEND_TIMEOUT to high values (e.g., 1200 or more) in your environment and ensure these are reflected in your nginx config. A 404 or 504 after a long wait is usually due to nginx or an external proxy terminating the request, not the Dify backend. Double-check your nginx config for proxy_read_timeout, proxy_send_timeout, and any error_page or proxy_intercept_errors directives that might rewrite upstream errors to 404 or 504. More info here and here.

After changing these settings, fully rebuild and restart all containers to apply the new configuration. If you use specific model providers (like Ollama), check for hardcoded timeouts in their code as well.

Finally, Dify's file download mechanism uses signed URLs that expire after a configurable timeout (FILES_ACCESS_TIMEOUT). If the frontend or session times out, the UI may lose state and fail to fetch output attachments, even if the backend completed the workflow. Make sure all session/cache TTLs and proxy timeouts are set high enough, and avoid letting the browser idle or switching tabs during long runs.

If you still have issues after these changes, check nginx and application logs at the time of the error to pinpoint which layer is causing the timeout.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

Hi, Dosu, thank you for the quick reply. Yes, it was indeed the issue of the TEXT_GENERATION_TIMEOUT_MS value being too low. This problem had been troubling me for several weeks, and the name of this parameter can indeed be somewhat misleading.

@nosee818 commented on GitHub (Dec 30, 2025): > Hi [@nosee818](https://github.com/nosee818)! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. > > Your issue is almost certainly caused by frontend or proxy timeouts that interrupt the connection before the long-running workflow completes, even though the backend finishes and the file is saved. In Dify, the frontend timeout is controlled by the `TEXT_GENERATION_TIMEOUT_MS` setting (default 60s). If your workflow takes longer, the UI will timeout and fail to fetch the output file, even if the backend succeeds. You should set `TEXT_GENERATION_TIMEOUT_MS` in your `.env` to a value at least as long as your expected workflow duration, and make sure it matches or exceeds `WORKFLOW_MAX_EXECUTION_TIME`, `GUNICORN_TIMEOUT`, and NGINX proxy timeouts. All these must be set high enough to support your longest workflows. See details [here](https://github.com/langgenius/dify/issues/28279#issuecomment-3540406109). > > Also, for self-hosted Docker setups, you need to set `NGINX_PROXY_READ_TIMEOUT` and `NGINX_PROXY_SEND_TIMEOUT` to high values (e.g., 1200 or more) in your environment and ensure these are reflected in your nginx config. A 404 or 504 after a long wait is usually due to nginx or an external proxy terminating the request, not the Dify backend. Double-check your nginx config for `proxy_read_timeout`, `proxy_send_timeout`, and any error_page or proxy_intercept_errors directives that might rewrite upstream errors to 404 or 504. More info [here](https://github.com/langgenius/dify/issues/23916#issuecomment-3187113652) and [here](https://github.com/langgenius/dify/issues/23502). > > After changing these settings, fully rebuild and restart all containers to apply the new configuration. If you use specific model providers (like Ollama), check for hardcoded timeouts in their code as well. > > Finally, Dify's file download mechanism uses signed URLs that expire after a configurable timeout (`FILES_ACCESS_TIMEOUT`). If the frontend or session times out, the UI may lose state and fail to fetch output attachments, even if the backend completed the workflow. Make sure all session/cache TTLs and proxy timeouts are set high enough, and avoid letting the browser idle or switching tabs during long runs. > > If you still have issues after these changes, check nginx and application logs at the time of the error to pinpoint which layer is causing the timeout. > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/901aaf97-1c6c-47b0-a4f9-3fadc9dad8f3?feedback_type=other) > > [![Chat with Dosu](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=Your%20issue%20is%20almost%20certainly%20caused%20by%20frontend%20or%20proxy%20timeouts%20that%20interrupt%20the%20connection%20before%20the%20long-running%20workflow%20completes%2C%20even%20though%20the%20backend%20finishes%20and%20the%20file%20is%20saved.%20In%20Dify%2C%20the%20frontend%20timeout%20is%20controlled%20by%20the%20%60TEXT_GENERATION_TIMEOUT_MS%60%20setting%20%28default%2060s%29.%20If%20your%20workflow%20takes%20longer%2C%20the%20UI%20will%20timeout%20and%20fail%20to%20fetch%20the%20output%20file%2C%20even%20if%20the%20backend%20succeeds.%20You%20should%20set%20%60TEXT_GENERATION_TIMEOUT_MS%60%20in%20your%20%60.env%60%20to%20a%20value%20at%20least%20as%20long%20as%20your%20expected%20workflow%20duration%2C%20and%20make%20sure%20it%20matches%20or%20exceeds%20%60WORKFLOW_MAX_EXECUTION_TIME%60%2C%20%60GUNICORN_TIMEOUT%60%2C%20and%20NGINX%20proxy%20timeouts.%20All%20these%20must%20be%20set%20high%20enough%20to%20support%20your%20longest%20workflows.%20See%20details%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/28279%23issuecomment-3540406109%29.%0A%0AAlso%2C%20for%20self-hosted%20Docker%20setups%2C%20you%20need%20to%20set%20%60NGINX_PROXY_READ_TIMEOUT%60%20and%20%60NGINX_PROXY_SEND_TIMEOUT%60%20to%20high%20values%20%28e.g.%2C%201200%20or%20more%29%20in%20your%20environment%20and%20ensure%20these%20are%20reflected%20in%20your%20nginx%20config.%20A%20404%20or%20504%20after%20a%20long%20wait%20is%20usually%20due%20to%20nginx%20or%20an%20external%20proxy%20terminating%20the%20request%2C%20not%20the%20Dify%20backend.%20Double-check%20your%20nginx%20config%20for%20%60proxy_read_timeout%60%2C%20%60proxy_send_timeout%60%2C%20and%20any%20error_page%20or%20proxy_intercept_errors%20directives%20that%20might%20rewrite%20upstream%20errors%20to%20404%20or%20504.%20More%20info%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/23916%23issuecomment-3187113652%29%20and%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/issues/23502%29.%0A%0AAfter%20changing%20these%20settings%2C%20fully%20rebuild%20and%20restart%20all%20containers%20to%20apply%20the%20new%20configuration.%20If%20you%20use%20specific%20model%20providers%20%28like%20Ollama%29%2C%20check%20for%20hardcoded%20timeouts%20in%20their%20code%20as%20well.%0A%0AFinally%2C%20Dify%27s%20file%20download%20mechanism%20uses%20signed%20URLs%20that%20expire%20after%20a%20configurable%20timeout%20%28%60FILES_ACCESS_TIMEOUT%60%29.%20If%20the%20frontend%20or%20session%20times%20out%2C%20the%20UI%20may%20lose%20state%20and%20fail%20to%20fetch%20output%20attachments%2C%20even%20if%20the%20backend%20completed%20the%20workflow.%20Make%20sure%20all%20session/cache%20TTLs%20and%20proxy%20timeouts%20are%20set%20high%20enough%2C%20and%20avoid%20letting%20the%20browser%20idle%20or%20switching%20tabs%20during%20long%20runs.%0A%0AIf%20you%20still%20have%20issues%20after%20these%20changes%2C%20check%20nginx%20and%20application%20logs%20at%20the%20time%20of%20the%20error%20to%20pinpoint%20which%20layer%20is%20causing%20the%20timeout.) [![Join Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30373) Hi, Dosu, thank you for the quick reply. Yes, it was indeed the issue of the TEXT_GENERATION_TIMEOUT_MS value being too low. This problem had been troubling me for several weeks, and the name of this parameter can indeed be somewhat misleading.
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#21366
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?