langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-26 18:36:52 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

"POST Request Fails for 40MB Files While 26MB Works - Config Changes Not Taking Effect" #19936

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

Originally created by @yanpx169 on GitHub (Oct 26, 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

Dify Version: 1.9.1

When I use the POST method of the HTTP request node to upload a file of 40.96MB, it remains in a "running" state.
However, when I switch to a 26MB file, everything works normally. I have also tested the API endpoint using Postman to upload a 40.96MB file, and it was successful, which proves that my backend service's API and transmission capabilities are functioning correctly.

I have already modified three configurations in the .env file as follows:
WORKFLOW_FILE_UPLOAD_LIMIT= 200 UPLOAD_FILE_SIZE_LIMIT= 100 NGINX_CLIENT_MAX_BODY_SIZE= 100M

What should I do to solve this problem and support uploading large files, for example, in the 40MB to 100MB range, to ensure they run normally? I look forward to your reply.

Image

✔️ Expected Behavior

When using the HTTP Request node to upload files via POST method:
​​File Size Within Configured Limits​​:
Files up to the configured size limit (UPLOAD_FILE_SIZE_LIMIT=100M) should upload successfully without getting stuck in a "running" state.
Both small (e.g., 26MB) and large (e.g., 40MB–100MB) files should process normally if they are below the configured limit.
​​Consistent Performance Across Tools​​:
If the same API endpoint successfully handles large file uploads (e.g., 40MB) via tools like Postman, the HTTP Request node in Dify should exhibit the same behavior.
​​Proper Error Handling​​:
If a file exceeds the configured limits, the system should reject it with a clear error message (e.g., "File size exceeds limit") rather than hanging indefinitely.
​​Configuration Respects Changes​​:
Adjustments to .envsettings (WORKFLOW_FILE_UPLOAD_LIMIT, UPLOAD_FILE_SIZE_LIMIT, NGINX_CLIENT_MAX_BODY_SIZE) should take immediate effect, allowing larger uploads as specified.
​​Stable Workflow Execution​​:
Uploads should complete within a reasonable time frame, transitioning to "success" or "failed" states without indefinite "running" status.
This ensures reliability and transparency when handling large file uploads in workflows.

❌ Actual Behavior

No response

Originally created by @yanpx169 on GitHub (Oct 26, 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 Dify Version: 1.9.1 When I use the POST method of the HTTP request node to upload a file of 40.96MB, it remains in a "running" state. However, when I switch to a 26MB file, everything works normally. I have also tested the API endpoint using Postman to upload a 40.96MB file, and it was successful, which proves that my backend service's API and transmission capabilities are functioning correctly. I have already modified three configurations in the .env file as follows: `WORKFLOW_FILE_UPLOAD_LIMIT= 200 UPLOAD_FILE_SIZE_LIMIT= 100 NGINX_CLIENT_MAX_BODY_SIZE= 100M` What should I do to solve this problem and support uploading large files, for example, in the 40MB to 100MB range, to ensure they run normally? I look forward to your reply. <img width="1091" height="868" alt="Image" src="https://github.com/user-attachments/assets/c7303a53-ec0f-42e0-8baa-3dc7cb0f075d" /> ### ✔️ Expected Behavior When using the HTTP Request node to upload files via POST method: ​​File Size Within Configured Limits​​: Files up to the configured size limit (UPLOAD_FILE_SIZE_LIMIT=100M) should upload successfully without getting stuck in a "running" state. Both small (e.g., 26MB) and large (e.g., 40MB–100MB) files should process normally if they are below the configured limit. ​​Consistent Performance Across Tools​​: If the same API endpoint successfully handles large file uploads (e.g., 40MB) via tools like Postman, the HTTP Request node in Dify should exhibit the same behavior. ​​Proper Error Handling​​: If a file exceeds the configured limits, the system should reject it with a clear error message (e.g., "File size exceeds limit") rather than hanging indefinitely. ​​Configuration Respects Changes​​: Adjustments to .envsettings (WORKFLOW_FILE_UPLOAD_LIMIT, UPLOAD_FILE_SIZE_LIMIT, NGINX_CLIENT_MAX_BODY_SIZE) should take immediate effect, allowing larger uploads as specified. ​​Stable Workflow Execution​​: Uploads should complete within a reasonable time frame, transitioning to "success" or "failed" states without indefinite "running" status. This ensures reliability and transparency when handling large file uploads in workflows. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:05:01 -05:00
yindo closed this issue 2026-02-21 20:05:01 -05:00
yindo commented 2026-02-21 20:05:01 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 26, 2025):

The reason your POST request hangs for 40MB files (while 26MB works and Postman succeeds) is that Dify's HTTP Request node does not enforce upload size limits internally for workflow-based uploads. The environment variables you set in .env (like UPLOAD_FILE_SIZE_LIMIT and WORKFLOW_FILE_UPLOAD_LIMIT) only apply to Dify's direct API file uploads, not to files sent through the HTTP Request node in a workflow. For workflow uploads, the only effective limits are those set by your reverse proxy (e.g., NGINX's client_max_body_size) or the remote API itself. If a file exceeds these limits, Dify does not provide a clear error and the workflow can hang indefinitely, as you've observed.

The default internal limit for the HTTP Request node's binary response size is 10MB, but there is no corresponding proactive check for upload size—so large uploads may hang if blocked by infrastructure or time out without feedback. Changes to .env do not affect this workflow node behavior; only web/proxy settings (like NGINX) can restrict these uploads, and Dify does not propagate clear errors for size exceedance at the workflow node level. This is a known limitation in v1.9.1 and is documented in related issues and code analysis (source, source).

To work around this, ensure your NGINX and Docker configs allow the desired file size, and consider splitting large files or handling uploads outside the workflow node if possible. For better error handling, you would need to add a file size check in your workflow logic or wait for a future Dify update that addresses this limitation.

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 (Oct 26, 2025): <!-- Answer --> The reason your POST request hangs for 40MB files (while 26MB works and Postman succeeds) is that Dify's HTTP Request node does not enforce upload size limits internally for workflow-based uploads. The environment variables you set in `.env` (like `UPLOAD_FILE_SIZE_LIMIT` and `WORKFLOW_FILE_UPLOAD_LIMIT`) only apply to Dify's direct API file uploads, not to files sent through the HTTP Request node in a workflow. For workflow uploads, the only effective limits are those set by your reverse proxy (e.g., NGINX's `client_max_body_size`) or the remote API itself. If a file exceeds these limits, Dify does not provide a clear error and the workflow can hang indefinitely, as you've observed. The default internal limit for the HTTP Request node's binary response size is 10MB, but there is no corresponding proactive check for upload size—so large uploads may hang if blocked by infrastructure or time out without feedback. Changes to `.env` do not affect this workflow node behavior; only web/proxy settings (like NGINX) can restrict these uploads, and Dify does not propagate clear errors for size exceedance at the workflow node level. This is a known limitation in v1.9.1 and is documented in related issues and code analysis ([source](https://github.com/langgenius/dify/blob/666586b59cdab7a4215919daa10a6737f45b6b17/api/configs/feature/__init__.py), [source](https://github.com/langgenius/dify/blob/666586b59cdab7a4215919daa10a6737f45b6b17/api/core/workflow/nodes/http_request/executor.py)). To work around this, ensure your NGINX and Docker configs allow the desired file size, and consider splitting large files or handling uploads outside the workflow node if possible. For better error handling, you would need to add a file size check in your workflow logic or wait for a future Dify update that addresses this limitation. <!-- 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/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?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/27471)
yindo commented 2026-02-21 20:05:01 -05:00
Author
Owner
Copy Link
Copy Source

@yanpx169 commented on GitHub (Oct 26, 2025):

The reason your POST request hangs for 40MB files (while 26MB works and Postman succeeds) is that Dify's HTTP Request node does not enforce upload size limits internally for workflow-based uploads. The environment variables you set in .env (like UPLOAD_FILE_SIZE_LIMIT and WORKFLOW_FILE_UPLOAD_LIMIT) only apply to Dify's direct API file uploads, not to files sent through the HTTP Request node in a workflow. For workflow uploads, the only effective limits are those set by your reverse proxy (e.g., NGINX's client_max_body_size) or the remote API itself. If a file exceeds these limits, Dify does not provide a clear error and the workflow can hang indefinitely, as you've observed.

The default internal limit for the HTTP Request node's binary response size is 10MB, but there is no corresponding proactive check for upload size—so large uploads may hang if blocked by infrastructure or time out without feedback. Changes to .env do not affect this workflow node behavior; only web/proxy settings (like NGINX) can restrict these uploads, and Dify does not propagate clear errors for size exceedance at the workflow node level. This is a known limitation in v1.9.1 and is documented in related issues and code analysis (source, source).

To work around this, ensure your NGINX and Docker configs allow the desired file size, and consider splitting large files or handling uploads outside the workflow node if possible. For better error handling, you would need to add a file size check in your workflow logic or wait for a future Dify update that addresses this limitation.

To reply, just mention @dosu.

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

@dosu
Thank you for the explanation. I'm still unclear about the Postman test bypassing reverse proxies - when I use the exact same API endpoint and parameters in Postman as I do in Dify's HTTP Request node (same URL, headers, and payload), doesn't this confirm that:
My backend service properly handles large file uploads
The network path between client and server is functional
The issue likely stems from Dify's HTTP Request node implementation?
Could you please provide detailed troubleshooting steps to:
Verify where exactly the upload gets stuck (Dify vs infrastructure)
Check for any hidden size limits in Dify's workflow execution
Capture meaningful error logs when this occurs
For example:
Should I monitor specific Docker container logs?
Are there debug flags to enable for the HTTP Request node?
How to test if the request even leaves Dify's backend?
A step-by-step diagnostic approach would be greatly appreciated, as the hanging behavior without errors makes this particularly difficult to debug.

@yanpx169 commented on GitHub (Oct 26, 2025): > The reason your POST request hangs for 40MB files (while 26MB works and Postman succeeds) is that Dify's HTTP Request node does not enforce upload size limits internally for workflow-based uploads. The environment variables you set in `.env` (like `UPLOAD_FILE_SIZE_LIMIT` and `WORKFLOW_FILE_UPLOAD_LIMIT`) only apply to Dify's direct API file uploads, not to files sent through the HTTP Request node in a workflow. For workflow uploads, the only effective limits are those set by your reverse proxy (e.g., NGINX's `client_max_body_size`) or the remote API itself. If a file exceeds these limits, Dify does not provide a clear error and the workflow can hang indefinitely, as you've observed. > > The default internal limit for the HTTP Request node's binary response size is 10MB, but there is no corresponding proactive check for upload size—so large uploads may hang if blocked by infrastructure or time out without feedback. Changes to `.env` do not affect this workflow node behavior; only web/proxy settings (like NGINX) can restrict these uploads, and Dify does not propagate clear errors for size exceedance at the workflow node level. This is a known limitation in v1.9.1 and is documented in related issues and code analysis ([source](https://github.com/langgenius/dify/blob/666586b59cdab7a4215919daa10a6737f45b6b17/api/configs/feature/__init__.py), [source](https://github.com/langgenius/dify/blob/666586b59cdab7a4215919daa10a6737f45b6b17/api/core/workflow/nodes/http_request/executor.py)). > > To work around this, ensure your NGINX and Docker configs allow the desired file size, and consider splitting large files or handling uploads outside the workflow node if possible. For better error handling, you would need to add a file size check in your workflow logic or wait for a future Dify update that addresses this limitation. > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b9d3362f-34ab-49ec-a8c1-9fdc092e4b0a?feedback_type=other)  [![Chat with Dosu](https://camo.githubusercontent.com/d9ffebb979729c9ef0fc4e3090dbae5b17cabbfec8afe378ada6b81913d6ad8a/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Join Discord](https://camo.githubusercontent.com/d562c2df5e4567ea41d37f1d91a4da0839d8341037045b103b2da268998de17f/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/4649f705e2396d6f328dbc8e800a0509c9c17b3b20253b36706c393df124b93d/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27471) @dosu Thank you for the explanation. I'm still unclear about the Postman test bypassing reverse proxies - when I use the exact same API endpoint and parameters in Postman as I do in Dify's HTTP Request node (same URL, headers, and payload), doesn't this confirm that: My backend service properly handles large file uploads The network path between client and server is functional The issue likely stems from Dify's HTTP Request node implementation? Could you please provide detailed troubleshooting steps to: Verify where exactly the upload gets stuck (Dify vs infrastructure) Check for any hidden size limits in Dify's workflow execution Capture meaningful error logs when this occurs For example: Should I monitor specific Docker container logs? Are there debug flags to enable for the HTTP Request node? How to test if the request even leaves Dify's backend? A step-by-step diagnostic approach would be greatly appreciated, as the hanging behavior without errors makes this particularly difficult to debug.
yindo commented 2026-02-21 20:05:01 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 26, 2025):

If Postman uploads succeed but Dify's HTTP Request node hangs, your backend and network are likely fine—the issue is probably in Dify's workflow execution or infrastructure between Dify and your API.

To pinpoint where uploads get stuck and capture meaningful logs:

  1. Enable global debug logging: Set the DEBUG flag to true in your deployment config or .env. This activates Dify's DebugLoggingLayer, which logs all workflow events, node starts, successes, failures, retries, and errors with input/output details. These logs help you see exactly where the workflow stalls or fails (source, source).

  2. Monitor the right Docker containers: Watch logs for the main Dify API and workflow executor containers. These handle workflow execution and node processing.

  3. Enable request/response logging: Set ENABLE_REQUEST_LOGGING to true in your config to log request and response bodies for deeper diagnostics (source).

  4. Check workflow logs for HTTP Request node events: Look for NodeRunStartedEvent, NodeRunSucceededEvent, NodeRunFailedEvent, and warnings/errors related to HttpRequestNodeError. The node logs request details in process_data and errors as warnings (source).

  5. Trace if the request leaves Dify: Compare timestamps and payloads in Dify logs, NGINX/proxy logs, and backend API logs. If you see the request in Dify but not in the proxy/backend, it's blocked by infrastructure. If it appears in all logs, but hangs, it's likely a workflow issue.

  6. Check for hidden file size limits: Dify does not enforce upload size limits in the HTTP Request node; limits are set by your proxy (NGINX) or backend. Double-check your proxy config (client_max_body_size) and backend API limits.

Step-by-step diagnostic workflow:

  • Enable DEBUG and ENABLE_REQUEST_LOGGING.
  • Reproduce the issue.
  • Monitor API/workflow executor logs for node events and errors.
  • Check proxy/backend logs for matching requests.
  • Compare with Postman results to isolate where the upload fails.

This approach should help you determine if the problem is in Dify, your proxy, or the backend, and provide actionable error logs for further debugging.

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 (Oct 26, 2025): <!-- Answer --> If Postman uploads succeed but Dify's HTTP Request node hangs, your backend and network are likely fine—the issue is probably in Dify's workflow execution or infrastructure between Dify and your API. To pinpoint where uploads get stuck and capture meaningful logs: 1. **Enable global debug logging**: Set the `DEBUG` flag to `true` in your deployment config or `.env`. This activates Dify's `DebugLoggingLayer`, which logs all workflow events, node starts, successes, failures, retries, and errors with input/output details. These logs help you see exactly where the workflow stalls or fails ([source](https://github.com/langgenius/dify/blob/ce5fe864305d21733ba34d7e478174571702e9d4/api/core/workflow/graph_engine/layers/debug_logging.py), [source](https://github.com/langgenius/dify/blob/ce5fe864305d21733ba34d7e478174571702e9d4/api/core/workflow/workflow_entry.py)). 2. **Monitor the right Docker containers**: Watch logs for the main Dify API and workflow executor containers. These handle workflow execution and node processing. 3. **Enable request/response logging**: Set `ENABLE_REQUEST_LOGGING` to `true` in your config to log request and response bodies for deeper diagnostics ([source](https://github.com/langgenius/dify/blob/ce5fe864305d21733ba34d7e478174571702e9d4/api/configs/deploy/__init__.py)). 4. **Check workflow logs for HTTP Request node events**: Look for `NodeRunStartedEvent`, `NodeRunSucceededEvent`, `NodeRunFailedEvent`, and warnings/errors related to `HttpRequestNodeError`. The node logs request details in `process_data` and errors as warnings ([source](https://github.com/langgenius/dify/blob/ce5fe864305d21733ba34d7e478174571702e9d4/api/core/workflow/nodes/http_request/node.py)). 5. **Trace if the request leaves Dify**: Compare timestamps and payloads in Dify logs, NGINX/proxy logs, and backend API logs. If you see the request in Dify but not in the proxy/backend, it's blocked by infrastructure. If it appears in all logs, but hangs, it's likely a workflow issue. 6. **Check for hidden file size limits**: Dify does not enforce upload size limits in the HTTP Request node; limits are set by your proxy (NGINX) or backend. Double-check your proxy config (`client_max_body_size`) and backend API limits. **Step-by-step diagnostic workflow**: - Enable `DEBUG` and `ENABLE_REQUEST_LOGGING`. - Reproduce the issue. - Monitor API/workflow executor logs for node events and errors. - Check proxy/backend logs for matching requests. - Compare with Postman results to isolate where the upload fails. This approach should help you determine if the problem is in Dify, your proxy, or the backend, and provide actionable error logs for further debugging. <!-- 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/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1a7c05be-1e2b-4ce6-b319-027d04316e25?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/27471)
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#19936
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?