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

Http Request Node Remain in the "running" state sometime #21413

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

Originally created by @wudiilong on GitHub (Jan 3, 2026).

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

Image I simply set up an HTTP request node for problem reproduction. The current issue is that the HTTP node always remains in the "running" state. The confirmed problem is that the URL path of the request is correct, it has been verified in the workflow, and it works after being published. The problem is that after Dify runs in the Docker for a period of time, the HTTP node becomes unavailable. This issue occurs not only in one workflow, but also in some parts of other workflows, but not all. Some HTTP nodes can work, while the HTTP node in the problem reproduction screenshot is definitely unavailable. I don't know what caused it to work initially but then become unavailable after running for a period of time and remaining in the "running" state. However, there is a solution, which is to restart the container. But after restarting, it will become unavailable again after some time. Image

✔️ Expected Behavior

Http Request Node is ok

❌ Actual Behavior

always running sometimes

Originally created by @wudiilong on GitHub (Jan 3, 2026). ### 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 <img width="1675" height="655" alt="Image" src="https://github.com/user-attachments/assets/d5436cb9-6933-4115-a5bf-ea1bd7fffe2e" /> I simply set up an HTTP request node for problem reproduction. The current issue is that the HTTP node always remains in the "running" state. The confirmed problem is that the URL path of the request is correct, it has been verified in the workflow, and it works after being published. The problem is that after Dify runs in the Docker for a period of time, the HTTP node becomes unavailable. This issue occurs not only in one workflow, but also in some parts of other workflows, but not all. Some HTTP nodes can work, while the HTTP node in the problem reproduction screenshot is definitely unavailable. I don't know what caused it to work initially but then become unavailable after running for a period of time and remaining in the "running" state. However, there is a solution, which is to restart the container. But after restarting, it will become unavailable again after some time. <img width="1085" height="688" alt="Image" src="https://github.com/user-attachments/assets/38fa8cec-4b9e-4b0c-8909-b22380f12c8c" /> ### ✔️ Expected Behavior Http Request Node is ok ### ❌ Actual Behavior always running sometimes
yindo added the 🐞 bug label 2026-02-21 20:12:26 -05:00
yindo closed this issue 2026-02-21 20:12:26 -05:00
yindo commented 2026-02-21 20:12:26 -05:00
Author
Owner
Copy Link
Copy Source

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

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

The most likely reasons your HTTP request node gets stuck in the "running" state are long-running or blocked retries, network/proxy misconfiguration, or resource exhaustion in your Docker environment. Dify's HTTP node uses configurable connect/read/write timeouts and retry logic, but if the downstream service never responds (or the connection pool is exhausted), the node can appear stuck while waiting for retries or timeouts to finish.

Here’s a focused checklist to help diagnose and mitigate the issue:

  1. Enable debug logging by setting LOG_LEVEL=DEBUG and ENABLE_REQUEST_LOGGING=True in your .env file, then reproduce the issue and check the logs for clues about stuck requests or resource exhaustion.
  2. Monitor your Docker/container resource usage (CPU, memory, open connections) when the problem occurs. If you see high usage or many open connections, try increasing Docker resource limits.
  3. Test network connectivity between containers using docker exec and curl to the target endpoint from inside the Dify container.
  4. Lower the HTTP node's timeout and retry values in your workflow to see if the node fails faster instead of hanging.
  5. If you use NGINX as a reverse proxy, increase NGINX_PROXY_READ_TIMEOUT, NGINX_PROXY_SEND_TIMEOUT, and disable proxy buffering (proxy_buffering off;) to avoid premature stream termination.
  6. Make sure all containers are on the same Docker network and use service names (not IPs) for inter-container calls.

If the issue persists, consider upgrading to the latest Dify version, as there have been recent fixes and improvements to HTTP node error handling and resource management.

If you can, share logs and resource stats from when the node is stuck—this will help pinpoint the root cause.

Relevant references:

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 (Jan 3, 2026): <!-- Greeting --> Hi @wudiilong! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> The most likely reasons your HTTP request node gets stuck in the "running" state are long-running or blocked retries, network/proxy misconfiguration, or resource exhaustion in your Docker environment. Dify's HTTP node uses configurable connect/read/write timeouts and retry logic, but if the downstream service never responds (or the connection pool is exhausted), the node can appear stuck while waiting for retries or timeouts to finish. Here’s a focused checklist to help diagnose and mitigate the issue: 1. Enable debug logging by setting `LOG_LEVEL=DEBUG` and `ENABLE_REQUEST_LOGGING=True` in your `.env` file, then reproduce the issue and check the logs for clues about stuck requests or resource exhaustion. 2. Monitor your Docker/container resource usage (CPU, memory, open connections) when the problem occurs. If you see high usage or many open connections, try increasing Docker resource limits. 3. Test network connectivity between containers using `docker exec` and `curl` to the target endpoint from inside the Dify container. 4. Lower the HTTP node's timeout and retry values in your workflow to see if the node fails faster instead of hanging. 5. If you use NGINX as a reverse proxy, increase `NGINX_PROXY_READ_TIMEOUT`, `NGINX_PROXY_SEND_TIMEOUT`, and disable proxy buffering (`proxy_buffering off;`) to avoid premature stream termination. 6. Make sure all containers are on the same Docker network and use service names (not IPs) for inter-container calls. If the issue persists, consider upgrading to the latest Dify version, as there have been recent fixes and improvements to HTTP node error handling and resource management. If you can, share logs and resource stats from when the node is stuck—this will help pinpoint the root cause. Relevant references: - [Timeouts, retries, and resource management in HTTP nodes](https://github.com/langgenius/dify/blob/815ae6c7548564510115d4f094a91add0a837004/api/core/workflow/nodes/http_request/node.py#L25-L222) - [HTTP client pooling and connection limits](https://github.com/langgenius/dify/blob/815ae6c7548564510115d4f094a91add0a837004/api/core/helper/http_client_pooling.py#L14-L59) - [Docker/NGINX timeout and proxy settings advice](https://github.com/langgenius/dify-official-plugins/issues/2157) <!-- 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/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4f8cf851-bf21-48e8-8b59-1367eadaf611?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=The%20most%20likely%20reasons%20your%20HTTP%20request%20node%20gets%20stuck%20in%20the%20%22running%22%20state%20are%20long-running%20or%20blocked%20retries%2C%20network/proxy%20misconfiguration%2C%20or%20resource%20exhaustion%20in%20your%20Docker%20environment.%20Dify%27s%20HTTP%20node%20uses%20configurable%20connect/read/write%20timeouts%20and%20retry%20logic%2C%20but%20if%20the%20downstream%20service%20never%20responds%20%28or%20the%20connection%20pool%20is%20exhausted%29%2C%20the%20node%20can%20appear%20stuck%20while%20waiting%20for%20retries%20or%20timeouts%20to%20finish.%0A%0AHere%E2%80%99s%20a%20focused%20checklist%20to%20help%20diagnose%20and%20mitigate%20the%20issue%3A%0A%0A1.%20Enable%20debug%20logging%20by%20setting%20%60LOG_LEVEL%3DDEBUG%60%20and%20%60ENABLE_REQUEST_LOGGING%3DTrue%60%20in%20your%20%60.env%60%20file%2C%20then%20reproduce%20the%20issue%20and%20check%20the%20logs%20for%20clues%20about%20stuck%20requests%20or%20resource%20exhaustion.%0A2.%20Monitor%20your%20Docker/container%20resource%20usage%20%28CPU%2C%20memory%2C%20open%20connections%29%20when%20the%20problem%20occurs.%20If%20you%20see%20high%20usage%20or%20many%20open%20connections%2C%20try%20increasing%20Docker%20resource%20limits.%0A3.%20Test%20network%20connectivity%20between%20containers%20using%20%60docker%20exec%60%20and%20%60curl%60%20to%20the%20target%20endpoint%20from%20inside%20the%20Dify%20container.%0A4.%20Lower%20the%20HTTP%20node%27s%20timeout%20and%20retry%20values%20in%20your%20workflow%20to%20see%20if%20the%20node%20fails%20faster%20instead%20of%20hanging.%0A5.%20If%20you%20use%20NGINX%20as%20a%20reverse%20proxy%2C%20increase%20%60NGINX_PROXY_READ_TIMEOUT%60%2C%20%60NGINX_PROXY_SEND_TIMEOUT%60%2C%20and%20disable%20proxy%20buffering%20%28%60proxy_buffering%20off%3B%60%29%20to%20avoid%20premature%20stream%20termination.%0A6.%20Make%20sure%20all%20containers%20are%20on%20the%20same%20Docker%20network%20and%20use%20service%20names%20%28not%20IPs%29%20for%20inter-container%20calls.%0A%0AIf%20the%20issue%20persists%2C%20consider%20upgrading%20to%20the%20latest%20Dify%20version%2C%20as%20there%20have%20been%20recent%20fixes%20and%20improvements%20to%20HTTP%20node%20error%20handling%20and%20resource%20management.%0A%0AIf%20you%20can%2C%20share%20logs%20and%20resource%20stats%20from%20when%20the%20node%20is%20stuck%E2%80%94this%20will%20help%20pinpoint%20the%20root%20cause.%20%0A%0ARelevant%20references%3A%20%20%0A-%20%5BTimeouts%2C%20retries%2C%20and%20resource%20management%20in%20HTTP%20nodes%5D%28https%3A//github.com/langgenius/dify/blob/815ae6c7548564510115d4f094a91add0a837004/api/core/workflow/nodes/http_request/node.py%23L25-L222%29%20%20%0A-%20%5BHTTP%20client%20pooling%20and%20connection%20limits%5D%28https%3A//github.com/langgenius/dify/blob/815ae6c7548564510115d4f094a91add0a837004/api/core/helper/http_client_pooling.py%23L14-L59%29%20%20%0A-%20%5BDocker/NGINX%20timeout%20and%20proxy%20settings%20advice%5D%28https%3A//github.com/langgenius/dify-official-plugins/issues/2157%29)&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/30486)
yindo commented 2026-02-21 20:12:26 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Jan 4, 2026):

Self Checks

  • I have read the Contributing Guide and Language Policy.[x] This is only for bug report, if you would like to ask a question, please head to Discussions.[x] I have searched for existing issues search for existing 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

Image I simply set up an HTTP request node for problem reproduction. The current issue is that the HTTP node always remains in the "running" state. The confirmed problem is that the URL path of the request is correct, it has been verified in the workflow, and it works after being published. The problem is that after Dify runs in the Docker for a period of time, the HTTP node becomes unavailable. This issue occurs not only in one workflow, but also in some parts of other workflows, but not all. Some HTTP nodes can work, while the HTTP node in the problem reproduction screenshot is definitely unavailable. I don't know what caused it to work initially but then become unavailable after running for a period of time and remaining in the "running" state. However, there is a solution, which is to restart the container. But after restarting, it will become unavailable again after some time. Image

✔️ Expected Behavior

Http Request Node is ok

❌ Actual Behavior

always running sometimes

what means of node unavailable ?

@fatelei commented on GitHub (Jan 4, 2026): > ### 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 > <img alt="Image" width="1675" height="655" src="https://private-user-images.githubusercontent.com/5927641/531675350-d5436cb9-6933-4115-a5bf-ea1bd7fffe2e.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njc1MTQ2MTQsIm5iZiI6MTc2NzUxNDMxNCwicGF0aCI6Ii81OTI3NjQxLzUzMTY3NTM1MC1kNTQzNmNiOS02OTMzLTQxMTUtYTViZi1lYTFiZDdmZmZlMmUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDEwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjAxMDRUMDgxMTU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OWRmY2NlYmEyZDAzMWNjMmI4NjAzZWVlNDQ0ODQwMjQzNzQ0MGQyYWIzNDI1NjYwMGQzOTIwOGE3OTJlZmVkNyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.rOrB5V57L76i8dByQYC_T0cYiPBqQDcTb7Pvd3iN30k"> I simply set up an HTTP request node for problem reproduction. The current issue is that the HTTP node always remains in the "running" state. The confirmed problem is that the URL path of the request is correct, it has been verified in the workflow, and it works after being published. The problem is that after Dify runs in the Docker for a period of time, the HTTP node becomes unavailable. This issue occurs not only in one workflow, but also in some parts of other workflows, but not all. Some HTTP nodes can work, while the HTTP node in the problem reproduction screenshot is definitely unavailable. I don't know what caused it to work initially but then become unavailable after running for a period of time and remaining in the "running" state. However, there is a solution, which is to restart the container. But after restarting, it will become unavailable again after some time. <img alt="Image" width="1085" height="688" src="https://private-user-images.githubusercontent.com/5927641/531675610-38fa8cec-4b9e-4b0c-8909-b22380f12c8c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njc1MTQ2MTQsIm5iZiI6MTc2NzUxNDMxNCwicGF0aCI6Ii81OTI3NjQxLzUzMTY3NTYxMC0zOGZhOGNlYy00YjllLTRiMGMtODkwOS1iMjIzODBmMTJjOGMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDEwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjAxMDRUMDgxMTU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NDhmYzdjM2FjYmFmMjE0NTkxNTZjZTNlZTg1N2ZiNzgxNjYzOWU5NGU2MDg0ODk0YTIyMTRlMDExODVkZTVjNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.2JX1VWFxMD1SScGTjJZvVnrBmTP_7SOibpygYJGf6C8"> > ### ✔️ Expected Behavior > Http Request Node is ok > > ### ❌ Actual Behavior > always running sometimes what means of node unavailable ?
yindo commented 2026-02-21 20:12:27 -05:00
Author
Owner
Copy Link
Copy Source

@wudiilong commented on GitHub (Jan 4, 2026):

自助检查

  • 我已阅读贡献指南和语言政策。[x] 此处仅用于提交错误报告，如有任何疑问，请前往讨论区。[x] 我已搜索过现有问题（包括已关闭的问题）。[x] 我确认我使用英语提交此报告，否则将被关闭。[x] 【中文用户和非英语用户】请使用英语提交，否则将被关闭：）[x] 请勿修改此模板 :) 并填写所有必填字段。

Dify 版本

1.11.2

云端托管或自托管

自托管（Docker）

重现步骤

图像我搭建了一个 HTTP 请求节点来重现问题。目前的问题是，这个 HTTP 节点始终处于“运行中”状态。已确认的问题是，请求的 URL 路径是正确的，已在工作流中验证过，并且发布后可以正常工作。问题在于，Dify 在 Docker 中运行一段时间后，这个 HTTP 节点就会变得不可用。这个问题不仅出现在一个工作流中，也出现在其他工作流的某些部分，但并非所有工作流都会出现这个问题。有些 HTTP 节点可以正常工作，而问题重现截图中的这个 HTTP 节点则肯定无法使用。我不知道是什么原因导致它最初可以正常工作，但在运行一段时间后却变得不可用并一直处于“运行中”状态。不过，有一个解决方法，那就是重启容器。但是重启后，过一段时间它又会再次变得不可用。图像

✔️预期行为

HTTP 请求节点正常

❌ 实际行为

有时总是运行

节点不可用是什么意思？

就是再次运行还会一直处于 running状态

@wudiilong commented on GitHub (Jan 4, 2026): > > ### 自助检查 > > > > > > * [x] 我已阅读[贡献指南](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md)和[语言政策](https://github.com/langgenius/dify/issues/1542)。[x] 此处仅用于提交错误报告，如有任何疑问，请前往[讨论区](https://github.com/langgenius/dify/discussions/categories/general)。[x] 我已搜索过现有[问题](https://github.com/langgenius/dify/issues)（包括已关闭的问题）。[x] 我确认我使用英语提交此报告，否则将被关闭。[x] 【中文用户和非英语用户】请使用英语提交，否则将被关闭：）[x] 请勿修改此模板 :) 并填写所有必填字段。 > > ### Dify 版本 > > 1.11.2 > > ### 云端托管或自托管 > > 自托管（Docker） > > ### 重现步骤 > > <img alt="图像" width="1675" height="655" src="https://private-user-images.githubusercontent.com/5927641/531675350-d5436cb9-6933-4115-a5bf-ea1bd7fffe2e.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njc1MTQ2MTQsIm5iZiI6MTc2NzUxNDMxNCwicGF0aCI6Ii81OTI3NjQxLzUzMTY3NTM1MC1kNTQzNmNiOS02OTMzLTQxMTUtYTViZi1lYTFiZDdmZmZlMmUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDEwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjAxMDRUMDgxMTU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OWRmY2NlYmEyZDAzMWNjMmI4NjAzZWVlNDQ0ODQwMjQzNzQ0MGQyYWIzNDI1NjYwMGQzOTIwOGE3OTJlZmVkNyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.rOrB5V57L76i8dByQYC_T0cYiPBqQDcTb7Pvd3iN30k">我搭建了一个 HTTP 请求节点来重现问题。目前的问题是，这个 HTTP 节点始终处于“运行中”状态。已确认的问题是，请求的 URL 路径是正确的，已在工作流中验证过，并且发布后可以正常工作。问题在于，Dify 在 Docker 中运行一段时间后，这个 HTTP 节点就会变得不可用。这个问题不仅出现在一个工作流中，也出现在其他工作流的某些部分，但并非所有工作流都会出现这个问题。有些 HTTP 节点可以正常工作，而问题重现截图中的这个 HTTP 节点则肯定无法使用。我不知道是什么原因导致它最初可以正常工作，但在运行一段时间后却变得不可用并一直处于“运行中”状态。不过，有一个解决方法，那就是重启容器。但是重启后，过一段时间它又会再次变得不可用。<img alt="图像" width="1085" height="688" src="https://private-user-images.githubusercontent.com/5927641/531675610-38fa8cec-4b9e-4b0c-8909-b22380f12c8c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njc1MTQ2MTQsIm5iZiI6MTc2NzUxNDMxNCwicGF0aCI6Ii81OTI3NjQxLzUzMTY3NTYxMC0zOGZhOGNlYy00YjllLTRiMGMtODkwOS1iMjIzODBmMTJjOGMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDEwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjAxMDRUMDgxMTU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NDhmYzdjM2FjYmFmMjE0NTkxNTZjZTNlZTg1N2ZiNzgxNjYzOWU5NGU2MDg0ODk0YTIyMTRlMDExODVkZTVjNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.2JX1VWFxMD1SScGTjJZvVnrBmTP_7SOibpygYJGf6C8"> > > ### ✔️预期行为 > > HTTP 请求节点正常 > > ### ❌ 实际行为 > > 有时总是运行 > > 节点不可用是什么意思？ 就是再次运行还会一直处于 running状态
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#21413
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?