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

Workflow Stalls After Upgrading Dify from 1.5.1 to 1.9.1 with Large HTTP Response #20409

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

Originally created by @Kanggrean on GitHub (Nov 19, 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.9.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1.Upgraded Dify from version 1.5.1 to 1.9.1.
2.The HTTP request response is approximately 50,000 characters.
3.In version 1.5.1, the workflow could successfully proceed to the next node.
4.In version 1.9.1:
1)Using Postman, it returns a 400 error.
2)Using the frontend UI to run the workflow, it stalls at this node.

✔️ Expected Behavior

We suspect this might be related to changes in output size handling or file upload restrictions introduced in version 1.9. Any guidance or suggestions on how to resolve this would be greatly appreciated.

❌ Actual Behavior

No response

Originally created by @Kanggrean on GitHub (Nov 19, 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.9.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1.Upgraded Dify from version 1.5.1 to 1.9.1. 2.The HTTP request response is approximately 50,000 characters. 3.In version 1.5.1, the workflow could successfully proceed to the next node. 4.In version 1.9.1: 1)Using Postman, it returns a 400 error. 2)Using the frontend UI to run the workflow, it stalls at this node. ### ✔️ Expected Behavior We suspect this might be related to changes in output size handling or file upload restrictions introduced in version 1.9. Any guidance or suggestions on how to resolve this would be greatly appreciated. ### ❌ Actual Behavior _No response_
yindo added the 🙏 help wantedstale labels 2026-02-21 20:07:19 -05:00
yindo closed this issue 2026-02-21 20:07:19 -05:00
yindo commented 2026-02-21 20:07:19 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 19, 2025):

In Dify 1.9.1, the HTTP Request node now enforces stricter internal limits on response size: by default, text responses are capped at 1 MB and binary responses at 10 MB. If a response exceeds these thresholds, the node raises an error and the workflow stalls or returns a 400 error, depending on how the error is surfaced in your setup. These limits are controlled by the environment variables HTTP_REQUEST_NODE_MAX_TEXT_SIZE and HTTP_REQUEST_NODE_MAX_BINARY_SIZE and can be adjusted in your .env file or Docker environment. For your case (~50,000 characters), you should be well under the 1 MB default, so if you're still seeing errors, double-check for any proxy (e.g., NGINX) or infrastructure limits that might be interfering, and ensure your .env overrides are being picked up by the API container.

Also, note that file upload limits set by UPLOAD_FILE_SIZE_LIMIT and similar variables do not affect the HTTP Request node—those only apply to direct file uploads via the Dify API or UI, not workflow HTTP requests. If you need to handle even larger responses, increase the relevant environment variable(s) and restart your containers. For more details, see the HTTP Request node executor code and feature config defaults.

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 (Nov 19, 2025): <!-- Answer --> In Dify 1.9.1, the HTTP Request node now enforces stricter internal limits on response size: by default, text responses are capped at 1 MB and binary responses at 10 MB. If a response exceeds these thresholds, the node raises an error and the workflow stalls or returns a 400 error, depending on how the error is surfaced in your setup. These limits are controlled by the environment variables `HTTP_REQUEST_NODE_MAX_TEXT_SIZE` and `HTTP_REQUEST_NODE_MAX_BINARY_SIZE` and can be adjusted in your `.env` file or Docker environment. For your case (~50,000 characters), you should be well under the 1 MB default, so if you're still seeing errors, double-check for any proxy (e.g., NGINX) or infrastructure limits that might be interfering, and ensure your `.env` overrides are being picked up by the API container. Also, note that file upload limits set by `UPLOAD_FILE_SIZE_LIMIT` and similar variables do not affect the HTTP Request node—those only apply to direct file uploads via the Dify API or UI, not workflow HTTP requests. If you need to handle even larger responses, increase the relevant environment variable(s) and restart your containers. For more details, see the [HTTP Request node executor code](https://github.com/langgenius/dify/blob/88c9b18cb679cc037be68ac5f168c6bc28809889/api/core/workflow/nodes/http_request/executor.py#L44-L368) and [feature config defaults](https://github.com/langgenius/dify/blob/88c9b18cb679cc037be68ac5f168c6bc28809889/api/configs/feature/__init__.py#L182-L652). <!-- 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/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/731c7446-4f01-4942-9dad-772b58a3d833?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/28394)
yindo commented 2026-02-21 20:07:19 -05:00
Author
Owner
Copy Link
Copy Source

@Kanggrean commented on GitHub (Nov 19, 2025):

Additional Error Details

Here are the logs from the API container when the workflow gets stuck after the HTTP node returns successfully.
The key issue appears after the response is received, during workflow execution storage — not during the HTTP request itself.

services.errors.file.FileTooLargeError
...
docker-api-1            | 2025-11-19 08:27:13.104 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://10.10.7.75:7643/test/report/audit/pdf "HTTP/1.1 200 OK"
docker-ssrf_proxy-1     | 1763540833.104  12196 172.18.0.10 TCP_MISS/200 47741 POST http://10.10.7.75:7643/test/report/audit/pdf - HIER_DIRECT/10.10.7.75 application/json
docker-sandbox-1        | [GIN] 2025/11/19 - 08:27:13 | 200 |   60.872551ms |      172.19.0.6 | POST     "/v1/sandbox/run"
docker-api-1            | 2025-11-19 08:27:13.735 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://sandbox:8194/v1/sandbox/run "HTTP/1.1 200 OK"
docker-api-1            | [2025-11-19 08:27:16 +0000] [41] [ERROR] Error handling request
docker-api-1            | Traceback (most recent call last):
docker-api-1            |   File "/app/api/.venv/lib/python3.12/site-packages/gunicorn/workers/base_async.py", line 114, in handle_request
docker-api-1            |     for item in respiter:
docker-api-1            |                 ^^^^^^^^
docker-api-1            |   File "/app/api/.venv/lib/python3.12/site-packages/werkzeug/wsgi.py", line 256, in __next__
docker-api-1            |     return self._next()
docker-api-1            |            ^^^^^^^^^^^^
docker-api-1            |   File "/app/api/.venv/lib/python3.12/site-packages/werkzeug/wrappers/response.py", line 32, in _iter_encoded
docker-api-1            |     for item in iterable:
docker-nginx-1          | 2025/11/19 08:27:16 [error] 26#26: *10334 upstream prematurely closed connection while reading upstream, client: 10.9.138.48, server: _, request: "POST /console/api/apps/852209b6-5482-455e-9d61-e3be04d32aa8/workflows/draft/run HTTP/1.1", upstream: "http://172.18.0.10:5001/console/api/apps/852209b6-5482-455e-9d61-e3be04d32aa8/workflows/draft/run", host: "10.13.5.27:8180", referrer: "http://10.13.5.27:8180/app/852209b6-5482-455e-9d61-e3be04d32aa8/workflow"
docker-api-1            |                 ^^^^^^^^
docker-api-1            |   File "/app/api/.venv/lib/python3.12/site-packages/flask/helpers.py", line 132, in generator
docker-api-1            |     yield from gen
docker-api-1            |   File "/app/api/libs/helper.py", line 207, in generate
docker-api-1            |     yield from response
docker-api-1            |   File "/app/api/core/app/features/rate_limiting/rate_limit.py", line 120, in __next__
docker-api-1            |     return next(self.generator)
docker-api-1            |            ^^^^^^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/core/app/apps/base_app_generator.py", line 176, in gen
docker-api-1            |     for message in generator:
docker-api-1            |                    ^^^^^^^^^
docker-api-1            |   File "/app/api/core/app/apps/base_app_generate_response_converter.py", line 27, in _generate_full_response
docker-api-1            |     yield from cls.convert_stream_full_response(response)
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_response_converter.py", line 46, in convert_stream_full_response
docker-api-1            |     for chunk in stream_response:
docker-api-1            |                  ^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 190, in _to_stream_response
docker-api-1            |     for stream_response in generator:
docker-api-1            |                            ^^^^^^^^^
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 221, in _wrapper_process_stream_response
docker-api-1            |     for response in self._process_stream_response(tts_publisher=tts_publisher, trace_manager=trace_manager):
docker-api-1            |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 686, in _process_stream_response
docker-api-1            |     if responses := list(
docker-api-1            |                     ^^^^^
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 615, in _dispatch_event
docker-api-1            |     yield from handler(
docker-api-1            |   File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 334, in _handle_node_succeeded_event
docker-api-1            |     workflow_node_execution = self._workflow_cycle_manager.handle_workflow_node_execution_success(event=event)
docker-api-1            |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/core/workflow/workflow_cycle_manager.py", line 193, in handle_workflow_node_execution_success
docker-api-1            |     self._workflow_node_execution_repository.save_execution_data(domain_execution)
docker-api-1            |   File "/app/api/core/repositories/sqlalchemy_workflow_node_execution_repository.py", line 451, in save_execution_data
docker-api-1            |     result = self._truncate_and_upload(
docker-api-1            |              ^^^^^^^^^^^^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/core/repositories/sqlalchemy_workflow_node_execution_repository.py", line 297, in _truncate_and_upload
docker-api-1            |     upload_file = self._file_service.upload_file(
docker-api-1            |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
docker-api-1            |   File "/app/api/services/file_service.py", line 70, in upload_file
docker-api-1            |     raise FileTooLargeError
docker-api-1            | services.errors.file.FileTooLargeError

Before the error, the HTTP request returns 200 OK:

HTTP Request: POST http://10.10.7.75:7643/test/report/audit/pdf "HTTP/1.1 200 OK"

Then the workflow fails here:

FileTooLargeError
_upstream prematurely closed connection

What's important:

  • The HTTP node returns ~50KB JSON successfully
  • The UI shows the response in Variable Inspector
  • But the workflow stalls and does not move to the next node
  • The crash happens when Dify tries to save execution data as a file

This did not happen in 1.5.1, but started after upgrading to 1.9.1, which suggests new behavior in:

 _truncate_and_upload()
 save_execution_data()
 workflow_node_execution_repository

It looks like even text-based HTTP responses are now being treated as file outputs and subject to file upload limits, causing the workflow to fail during persistence—not during HTTP processing.

My Question

Is the HTTP node in 1.9.1 now saving responses to file storage by default, causing normal JSON output to be routed through the upload_file() pipeline and triggering FileTooLargeError?

If so:

  • How can I disable file-based persistence for HTTP responses?
  • Or how do I configure the size limit specifically for workflow execution storage (not uploads and not HTTP node text size)?

Let me know if you need a reproducible workflow or more logs.

@Kanggrean commented on GitHub (Nov 19, 2025): ### Additional Error Details Here are the logs from the API container when the workflow gets stuck after the HTTP node returns successfully. The key issue appears *after* the response is received, during workflow execution storage — not during the HTTP request itself. ``` services.errors.file.FileTooLargeError ... docker-api-1 | 2025-11-19 08:27:13.104 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://10.10.7.75:7643/test/report/audit/pdf "HTTP/1.1 200 OK" docker-ssrf_proxy-1 | 1763540833.104 12196 172.18.0.10 TCP_MISS/200 47741 POST http://10.10.7.75:7643/test/report/audit/pdf - HIER_DIRECT/10.10.7.75 application/json docker-sandbox-1 | [GIN] 2025/11/19 - 08:27:13 | 200 | 60.872551ms | 172.19.0.6 | POST "/v1/sandbox/run" docker-api-1 | 2025-11-19 08:27:13.735 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://sandbox:8194/v1/sandbox/run "HTTP/1.1 200 OK" docker-api-1 | [2025-11-19 08:27:16 +0000] [41] [ERROR] Error handling request docker-api-1 | Traceback (most recent call last): docker-api-1 | File "/app/api/.venv/lib/python3.12/site-packages/gunicorn/workers/base_async.py", line 114, in handle_request docker-api-1 | for item in respiter: docker-api-1 | ^^^^^^^^ docker-api-1 | File "/app/api/.venv/lib/python3.12/site-packages/werkzeug/wsgi.py", line 256, in __next__ docker-api-1 | return self._next() docker-api-1 | ^^^^^^^^^^^^ docker-api-1 | File "/app/api/.venv/lib/python3.12/site-packages/werkzeug/wrappers/response.py", line 32, in _iter_encoded docker-api-1 | for item in iterable: docker-nginx-1 | 2025/11/19 08:27:16 [error] 26#26: *10334 upstream prematurely closed connection while reading upstream, client: 10.9.138.48, server: _, request: "POST /console/api/apps/852209b6-5482-455e-9d61-e3be04d32aa8/workflows/draft/run HTTP/1.1", upstream: "http://172.18.0.10:5001/console/api/apps/852209b6-5482-455e-9d61-e3be04d32aa8/workflows/draft/run", host: "10.13.5.27:8180", referrer: "http://10.13.5.27:8180/app/852209b6-5482-455e-9d61-e3be04d32aa8/workflow" docker-api-1 | ^^^^^^^^ docker-api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask/helpers.py", line 132, in generator docker-api-1 | yield from gen docker-api-1 | File "/app/api/libs/helper.py", line 207, in generate docker-api-1 | yield from response docker-api-1 | File "/app/api/core/app/features/rate_limiting/rate_limit.py", line 120, in __next__ docker-api-1 | return next(self.generator) docker-api-1 | ^^^^^^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/core/app/apps/base_app_generator.py", line 176, in gen docker-api-1 | for message in generator: docker-api-1 | ^^^^^^^^^ docker-api-1 | File "/app/api/core/app/apps/base_app_generate_response_converter.py", line 27, in _generate_full_response docker-api-1 | yield from cls.convert_stream_full_response(response) docker-api-1 | File "/app/api/core/app/apps/workflow/generate_response_converter.py", line 46, in convert_stream_full_response docker-api-1 | for chunk in stream_response: docker-api-1 | ^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 190, in _to_stream_response docker-api-1 | for stream_response in generator: docker-api-1 | ^^^^^^^^^ docker-api-1 | File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 221, in _wrapper_process_stream_response docker-api-1 | for response in self._process_stream_response(tts_publisher=tts_publisher, trace_manager=trace_manager): docker-api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 686, in _process_stream_response docker-api-1 | if responses := list( docker-api-1 | ^^^^^ docker-api-1 | File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 615, in _dispatch_event docker-api-1 | yield from handler( docker-api-1 | File "/app/api/core/app/apps/workflow/generate_task_pipeline.py", line 334, in _handle_node_succeeded_event docker-api-1 | workflow_node_execution = self._workflow_cycle_manager.handle_workflow_node_execution_success(event=event) docker-api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/core/workflow/workflow_cycle_manager.py", line 193, in handle_workflow_node_execution_success docker-api-1 | self._workflow_node_execution_repository.save_execution_data(domain_execution) docker-api-1 | File "/app/api/core/repositories/sqlalchemy_workflow_node_execution_repository.py", line 451, in save_execution_data docker-api-1 | result = self._truncate_and_upload( docker-api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/core/repositories/sqlalchemy_workflow_node_execution_repository.py", line 297, in _truncate_and_upload docker-api-1 | upload_file = self._file_service.upload_file( docker-api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ docker-api-1 | File "/app/api/services/file_service.py", line 70, in upload_file docker-api-1 | raise FileTooLargeError docker-api-1 | services.errors.file.FileTooLargeError ``` Before the error, the HTTP request **returns 200 OK**: ``` HTTP Request: POST http://10.10.7.75:7643/test/report/audit/pdf "HTTP/1.1 200 OK" ``` Then the workflow fails here: ``` FileTooLargeError _upstream prematurely closed connection ``` What's important: * The HTTP node **returns ~50KB JSON successfully** * The UI shows the response in **Variable Inspector** * But the workflow **stalls and does not move to the next node** * The crash happens when Dify tries to **save execution data as a file** This did **not happen in 1.5.1**, but started after upgrading to **1.9.1**, which suggests new behavior in: ``` _truncate_and_upload() save_execution_data() workflow_node_execution_repository ``` It looks like even text-based HTTP responses are now being treated as file outputs and subject to file upload limits, causing the workflow to fail during persistence—not during HTTP processing. --- ### My Question Is the HTTP node in 1.9.1 now saving responses to file storage by default, causing normal JSON output to be routed through the `upload_file()` pipeline and triggering `FileTooLargeError`? If so: * How can I disable file-based persistence for HTTP responses? * Or how do I configure the size limit specifically for workflow execution storage (not uploads and not HTTP node text size)? Let me know if you need a reproducible workflow or more logs.
yindo commented 2026-02-21 20:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 19, 2025):

In Dify 1.9.1, workflow node outputs (including HTTP node responses) are only persisted as files if they exceed the truncation threshold set by the workflow variable truncator. For typical JSON/text outputs, if the data is larger than the configured truncation limit, Dify offloads the full content to file storage using the same upload logic as user file uploads, which is where the FileTooLargeError comes from if the file size exceeds the configured limit (source, source).

You can control this behavior by adjusting these environment variables in your .env file:

  • WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE (default: ~1MB): Increase this to allow larger variables to be stored inline in the database, avoiding file offload for bigger JSON/text outputs.
  • UPLOAD_FILE_SIZE_LIMIT (default: 15MB): Increase this if you want to allow larger files to be offloaded without triggering FileTooLargeError.

There is no direct config to disable file-based persistence for HTTP node responses, but by raising the truncation threshold, you can keep more data inline and avoid file offloading for most cases. For reference, the relevant configs are in api/configs/feature/__init__.py.

If you want to avoid file offloading entirely for workflow execution data, set WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE to a value higher than your largest expected output. If you need to allow larger files, increase UPLOAD_FILE_SIZE_LIMIT accordingly. No changes are needed for HTTP node text size limits unless your responses are extremely large.

Let me know if you need help with the exact .env settings or want to discuss edge cases!

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 (Nov 19, 2025): <!-- Answer --> In Dify 1.9.1, workflow node outputs (including HTTP node responses) are only persisted as files if they exceed the truncation threshold set by the workflow variable truncator. For typical JSON/text outputs, if the data is larger than the configured truncation limit, Dify offloads the full content to file storage using the same upload logic as user file uploads, which is where the `FileTooLargeError` comes from if the file size exceeds the configured limit ([source](https://github.com/langgenius/dify/blob/012877d8d4602fada732fd8f81ee7e15ee74194b/api/core/repositories/sqlalchemy_workflow_node_execution_repository.py#L38-L460), [source](https://github.com/langgenius/dify/blob/012877d8d4602fada732fd8f81ee7e15ee74194b/api/services/file_service.py#L42-L124)). You can control this behavior by adjusting these environment variables in your `.env` file: - `WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE` (default: ~1MB): Increase this to allow larger variables to be stored inline in the database, avoiding file offload for bigger JSON/text outputs. - `UPLOAD_FILE_SIZE_LIMIT` (default: 15MB): Increase this if you want to allow larger files to be offloaded without triggering `FileTooLargeError`. There is no direct config to disable file-based persistence for HTTP node responses, but by raising the truncation threshold, you can keep more data inline and avoid file offloading for most cases. For reference, the relevant configs are in [`api/configs/feature/__init__.py`](https://github.com/langgenius/dify/blob/012877d8d4602fada732fd8f81ee7e15ee74194b/api/configs/feature/__init__.py#L323-L690). If you want to avoid file offloading entirely for workflow execution data, set `WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE` to a value higher than your largest expected output. If you need to allow larger files, increase `UPLOAD_FILE_SIZE_LIMIT` accordingly. No changes are needed for HTTP node text size limits unless your responses are extremely large. Let me know if you need help with the exact `.env` settings or want to discuss edge cases! <!-- 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/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2f019cf0-48ae-4ebf-a246-12a3d29350d6?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/28394)
yindo commented 2026-02-21 20:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@Kanggrean commented on GitHub (Nov 20, 2025):

I change UPLOAD_FILE_SIZE_LIMIT to 100MB, but it not work。It's also

docker-api-1 | File "/app/api/services/file_service.py", line 70, in upload_file
docker-api-1 | raise FileTooLargeError
docker-api-1 | services.errors.file.FileTooLargeError

@Kanggrean commented on GitHub (Nov 20, 2025): I change UPLOAD_FILE_SIZE_LIMIT to 100MB, but it not work。It's also docker-api-1 | File "/app/api/services/file_service.py", line 70, in upload_file docker-api-1 | raise FileTooLargeError docker-api-1 | services.errors.file.FileTooLargeError
yindo commented 2026-02-21 20:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Nov 25, 2025):

I change UPLOAD_FILE_SIZE_LIMIT to 100MB, but it not work。It's also

docker-api-1 | File "/app/api/services/file_service.py", line 70, in upload_file docker-api-1 | raise FileTooLargeError docker-api-1 | services.errors.file.FileTooLargeError

update env and restart docker

@fatelei commented on GitHub (Nov 25, 2025): > I change UPLOAD_FILE_SIZE_LIMIT to 100MB, but it not work。It's also > > docker-api-1 | File "/app/api/services/file_service.py", line 70, in upload_file docker-api-1 | raise FileTooLargeError docker-api-1 | services.errors.file.FileTooLargeError update env and restart docker
yindo commented 2026-02-21 20:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 2, 2026):

Hi, @Kanggrean. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that after upgrading from Dify 1.5.1 to 1.9.1, workflows with large (~50KB) HTTP responses stall or error with FileTooLargeError during execution data saving.
  • The error occurs not during the HTTP request but when saving execution data due to file size limits.
  • I explained that large node outputs are offloaded to file storage with size limits controlled by environment variables like WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE and UPLOAD_FILE_SIZE_LIMIT.
  • You increased UPLOAD_FILE_SIZE_LIMIT to 100MB but still encountered the error.
  • Maintainer fatelei suggested verifying environment variable updates and restarting Docker containers to apply changes.

Next Steps:

  • Please confirm if this issue persists with the latest version of Dify and after ensuring environment variables are correctly set and containers restarted.
  • If the problem is still relevant, you can keep the discussion open by commenting on this issue; otherwise, it will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 2, 2026): Hi, @Kanggrean. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that after upgrading from Dify 1.5.1 to 1.9.1, workflows with large (~50KB) HTTP responses stall or error with FileTooLargeError during execution data saving. - The error occurs not during the HTTP request but when saving execution data due to file size limits. - I explained that large node outputs are offloaded to file storage with size limits controlled by environment variables like WORKFLOW_VARIABLE_TRUNCATION_MAX_SIZE and UPLOAD_FILE_SIZE_LIMIT. - You increased UPLOAD_FILE_SIZE_LIMIT to 100MB but still encountered the error. - Maintainer fatelei suggested verifying environment variable updates and restarting Docker containers to apply changes. **Next Steps:** - Please confirm if this issue persists with the latest version of Dify and after ensuring environment variables are correctly set and containers restarted. - If the problem is still relevant, you can keep the discussion open by commenting on this issue; otherwise, it will be automatically closed in 15 days. Thank you for your understanding and contribution!
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 stale 🙏 help wanted
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#20409
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?