langgenius/dify-official-plugins
1
0
Fork 0
mirror of https://github.com/langgenius/dify-official-plugins.git synced 2026-07-21 17:45:23 -04:00
Code Issues 54 Packages Projects Releases Wiki Activity

Ollama read timeout=300 #568

New Issue
Closed
opened 2026-02-16 10:19:46 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 10:19:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @naisy on GitHub (Aug 19, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues Dify issues & Dify Official Plugins, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.2

Plugin version

langgenius-ollama 0.0.7

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Steps to Reproduce

  1. Download the Ollama plugin from:
    https://marketplace.dify.ai/plugins/langgenius/ollama
  2. Unzip the package:
    langgenius-ollama_0.0.7.difypkg
  3. Open the file:
    langgenius-ollama_0.0.7/models/llm/llm.py
  4. You will find the following code:
        response = requests.post(
            endpoint_url, headers=headers, json=data, timeout=(10, 300), stream=stream
        )

Description

In the Ollama plugin (langgenius-ollama v0.0.7), the default timeout is hardcoded as timeout=(10, 300).
This causes requests to fail if the model takes longer than 300 seconds to respond.

Problem

  • When using larger models, long prompts, or generating large outputs, the 300-second read timeout is often exceeded.
  • As a result, the HTTP request fails with a read timeout (requests.post(..., timeout=(10, 300))), and Dify cannot get a response from Ollama.

Cause

The timeout is hardcoded in the plugin’s source code (models/llm/llm.py), making it impossible for users to override.

✔️ Error log

2025-08-19 12:46:05.032 ERROR [ThreadPoolExecutor-21_0] [base.py:211] - Error in stream reponse for plugin {'code': -500, 'message': '{"message":"{\\"args\\":{\\"description\\":\\"[models] Connection Error, HTTPConnectionPool(host=\'host.docker.internal\', port=11434): Read timed out. (read timeout=300)\\"},\\"error_type\\":\\"InvokeConnectionError\\",\\"message\\":\\"[models] Connection Error, HTTPConnectionPool(host=\'host.docker.internal\', port=11434): Read timed out. (read timeout=300)\\"}","error_type":"PluginInvokeError","args":null}', 'data': None}
Originally created by @naisy on GitHub (Aug 19, 2025). ### Self Checks - [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 [Dify issues](https://github.com/langgenius/dify/issues) & [Dify Official Plugins](https://github.com/langgenius/dify-official-plugins/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.2 ### Plugin version langgenius-ollama 0.0.7 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce ### Steps to Reproduce 1. Download the Ollama plugin from: https://marketplace.dify.ai/plugins/langgenius/ollama 2. Unzip the package: `langgenius-ollama_0.0.7.difypkg` 3. Open the file: `langgenius-ollama_0.0.7/models/llm/llm.py` 4. You will find the following code: ``` response = requests.post( endpoint_url, headers=headers, json=data, timeout=(10, 300), stream=stream ) ``` ### Description In the Ollama plugin (**langgenius-ollama v0.0.7**), the default timeout is hardcoded as `timeout=(10, 300)`. This causes requests to fail if the model takes longer than 300 seconds to respond. --- ### Problem - When using larger models, long prompts, or generating large outputs, the 300-second read timeout is often exceeded. - As a result, the HTTP request fails with a read timeout (`requests.post(..., timeout=(10, 300))`), and Dify cannot get a response from Ollama. --- ### Cause The timeout is hardcoded in the plugin’s source code (models/llm/llm.py), making it impossible for users to override. ### ✔️ Error log ``` 2025-08-19 12:46:05.032 ERROR [ThreadPoolExecutor-21_0] [base.py:211] - Error in stream reponse for plugin {'code': -500, 'message': '{"message":"{\\"args\\":{\\"description\\":\\"[models] Connection Error, HTTPConnectionPool(host=\'host.docker.internal\', port=11434): Read timed out. (read timeout=300)\\"},\\"error_type\\":\\"InvokeConnectionError\\",\\"message\\":\\"[models] Connection Error, HTTPConnectionPool(host=\'host.docker.internal\', port=11434): Read timed out. (read timeout=300)\\"}","error_type":"PluginInvokeError","args":null}', 'data': None} ```
yindo added the bug label 2026-02-16 10:19:46 -05:00
yindo closed this issue 2026-02-16 10:19:46 -05:00
yindo commented 2026-02-16 10:19:46 -05:00
Author
Owner
Copy Link
Copy Source

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

The Ollama plugin's 300-second read timeout is hardcoded in the source code and is not user-configurable as of v0.0.7. This means that for long-running requests (like large models or outputs), you'll hit a timeout unless you manually change the code. To work around this, you need to edit the timeout value in the plugin's Python file (for example, change timeout=(10, 300) to timeout=(10, 3600)) and then rebuild your Docker containers for the change to take effect. You may also want to update related environment variables in your Docker .env file, but these do not override the hardcoded plugin timeout unless you also change the code itself [source].

Other plugins (like gpustack and huggingface_tei) have recently added configurable timeout parameters via plugin settings or YAML config, but the Ollama plugin has not yet adopted this approach [source]. If you want a more flexible solution, you could suggest or implement a similar change for the Ollama plugin.

Let me know if you want step-by-step instructions for updating the code and rebuilding your Docker setup.

To reply, just mention @dosu.

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

@dosubot[bot] commented on GitHub (Aug 19, 2025): <!-- Answer --> The Ollama plugin's 300-second read timeout is hardcoded in the source code and is not user-configurable as of v0.0.7. This means that for long-running requests (like large models or outputs), you'll hit a timeout unless you manually change the code. To work around this, you need to edit the timeout value in the plugin's Python file (for example, change `timeout=(10, 300)` to `timeout=(10, 3600)`) and then rebuild your Docker containers for the change to take effect. You may also want to update related environment variables in your Docker `.env` file, but these do not override the hardcoded plugin timeout unless you also change the code itself [[source]](https://github.com/langgenius/dify/issues/12987). Other plugins (like gpustack and huggingface_tei) have recently added configurable timeout parameters via plugin settings or YAML config, but the Ollama plugin has not yet adopted this approach [[source]](https://github.com/langgenius/dify-official-plugins/pull/1087). If you want a more flexible solution, you could suggest or implement a similar change for the Ollama plugin. Let me know if you want step-by-step instructions for updating the code and rebuilding your Docker setup. <!-- 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/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a4e5a501-1f9d-429f-8f01-2a4eb5697e68?feedback_type=other)</sup>&nbsp;&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-official-plugins/issues/1529)
yindo commented 2026-02-16 10:19:47 -05:00
Author
Owner
Copy Link
Copy Source

@naisy commented on GitHub (Aug 19, 2025):

Thanks for the clarification earlier!
I tried making a small modification to the plugin to address this issue.

What I changed

  • Updated llm.py to add connect_timeout and read_timeout as configurable fields in the plugin UI.
  • Set read_timeout to -1 (no limit) by default.
Image

Why

My workflow runs 10 parallel iteration nodes, each containing 4 chained LLMs.
That means 40 nodes in total. Changing the timeout setting for each node manually is not practical.
By setting the default read_timeout=-1, I can avoid unnecessary configuration overhead.

Diff

--- llm.py.org	2025-08-20 11:22:26.821549848 +0900
+++ llm.py	2025-08-20 11:21:37.607376662 +0900
@@ -176,6 +176,16 @@
         endpoint_url = credentials["base_url"]
         if not endpoint_url.endswith("/"):
             endpoint_url += "/"
+
+        # Make connect timeout configurable (default to 10 if not specified)
+        connect_timeout = int(model_parameters.pop("connect_timeout", 10))
+        # Make read timeout configurable (default to -1 if not specified)
+        read_timeout = int(model_parameters.pop("read_timeout", -1))
+
+        # Convert -1 to None (meaning no timeout / infinite)
+        connect_timeout = None if connect_timeout == -1 else connect_timeout
+        read_timeout = None if read_timeout == -1 else read_timeout
+
         data = {"model": model, "stream": stream}
         if "format" in model_parameters:
             data["format"] = model_parameters["format"]
@@ -235,7 +245,7 @@
                     data["prompt"] = text
                     data["images"] = images
         response = requests.post(
-            endpoint_url, headers=headers, json=data, timeout=(10, 300), stream=stream
+            endpoint_url, headers=headers, json=data, timeout=(connect_timeout, read_timeout), stream=stream
         )
         response.encoding = "utf-8"
         if response.status_code != 200:
@@ -538,6 +548,30 @@
             },
             parameter_rules=[
                 ParameterRule(
+                    name="connect_timeout",
+                    label=I18nObject(en_US="Connect Timeout (s)", zh_Hans="连接超时(秒)"),
+                    type=ParameterType.INT,
+                    help=I18nObject(
+                        en_US="Connection timeout in seconds. Use -1 for infinite (no timeout). Default: 10",
+                        zh_Hans="连接超时（秒）。使用 -1 表示无限（无超时）。默认 10"
+                        ),
+                    default=10,
+                    min=-1,
+                    max=86400,
+                ),
+                ParameterRule(
+                    name="read_timeout",
+                    label=I18nObject(en_US="Read Timeout (s)", zh_Hans="读取超时(秒)"),
+                    type=ParameterType.INT,
+                    help=I18nObject(
+                        en_US="Read timeout in seconds. Use -1 for infinite (no timeout). Default: -1",
+                        zh_Hans="读取超时（秒）。使用 -1 表示无限（无超时）。默认 -1"
+                        ),
+                    default=-1,
+                    min=-1,
+                    max=86400,
+                ),
+                ParameterRule(
                     name=DefaultParameterName.TEMPERATURE.value,
                     use_template=DefaultParameterName.TEMPERATURE.value,
                     label=I18nObject(en_US="Temperature", zh_Hans="温度"),

Suggestion

It would be great if this kind of improvement could be incorporated into the official Ollama plugin.
At the very least, making the timeout configurable via the plugin UI would make it much more user-friendly for complex workflows.

@naisy commented on GitHub (Aug 19, 2025): Thanks for the clarification earlier! I tried making a small modification to the plugin to address this issue. ### What I changed - Updated `llm.py` to add **`connect_timeout`** and **`read_timeout`** as configurable fields in the plugin UI. - Set **`read_timeout`** to `-1` (no limit) by default. <img width="1369" height="792" alt="Image" src="https://github.com/user-attachments/assets/bc7407a3-3655-4e99-934c-4adda6c66320" /> ### Why My workflow runs **10 parallel iteration nodes**, each containing **4 chained LLMs**. That means 40 nodes in total. Changing the timeout setting for each node manually is not practical. By setting the default `read_timeout=-1`, I can avoid unnecessary configuration overhead. ### Diff ``` --- llm.py.org 2025-08-20 11:22:26.821549848 +0900 +++ llm.py 2025-08-20 11:21:37.607376662 +0900 @@ -176,6 +176,16 @@ endpoint_url = credentials["base_url"] if not endpoint_url.endswith("/"): endpoint_url += "/" + + # Make connect timeout configurable (default to 10 if not specified) + connect_timeout = int(model_parameters.pop("connect_timeout", 10)) + # Make read timeout configurable (default to -1 if not specified) + read_timeout = int(model_parameters.pop("read_timeout", -1)) + + # Convert -1 to None (meaning no timeout / infinite) + connect_timeout = None if connect_timeout == -1 else connect_timeout + read_timeout = None if read_timeout == -1 else read_timeout + data = {"model": model, "stream": stream} if "format" in model_parameters: data["format"] = model_parameters["format"] @@ -235,7 +245,7 @@ data["prompt"] = text data["images"] = images response = requests.post( - endpoint_url, headers=headers, json=data, timeout=(10, 300), stream=stream + endpoint_url, headers=headers, json=data, timeout=(connect_timeout, read_timeout), stream=stream ) response.encoding = "utf-8" if response.status_code != 200: @@ -538,6 +548,30 @@ }, parameter_rules=[ ParameterRule( + name="connect_timeout", + label=I18nObject(en_US="Connect Timeout (s)", zh_Hans="连接超时(秒)"), + type=ParameterType.INT, + help=I18nObject( + en_US="Connection timeout in seconds. Use -1 for infinite (no timeout). Default: 10", + zh_Hans="连接超时（秒）。使用 -1 表示无限（无超时）。默认 10" + ), + default=10, + min=-1, + max=86400, + ), + ParameterRule( + name="read_timeout", + label=I18nObject(en_US="Read Timeout (s)", zh_Hans="读取超时(秒)"), + type=ParameterType.INT, + help=I18nObject( + en_US="Read timeout in seconds. Use -1 for infinite (no timeout). Default: -1", + zh_Hans="读取超时（秒）。使用 -1 表示无限（无超时）。默认 -1" + ), + default=-1, + min=-1, + max=86400, + ), + ParameterRule( name=DefaultParameterName.TEMPERATURE.value, use_template=DefaultParameterName.TEMPERATURE.value, label=I18nObject(en_US="Temperature", zh_Hans="温度"), ``` ### Suggestion It would be great if this kind of improvement could be incorporated into the official Ollama plugin. At the very least, making the timeout configurable via the plugin UI would make it much more user-friendly for complex workflows.
yindo commented 2026-02-16 10:19:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 5, 2025):

Hi, @naisy. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that the Ollama plugin (v0.0.7) had a hardcoded 300-second HTTP read timeout causing failures with large models or long prompts.
  • It was confirmed that changing this timeout required editing plugin code and rebuilding Docker containers.
  • You proposed and shared a code modification to add configurable connect and read timeout parameters in the plugin UI.
  • The read_timeout default was set to -1 (no limit) to better support complex workflows with many parallel LLM calls.
  • This enhancement was positively received and suggested for official adoption.

Next Steps:

  • Please confirm if this issue is still relevant to the latest version of the dify-official-plugins repository by commenting here.
  • If no further updates are provided, I will automatically close this issue in 5 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Sep 5, 2025): Hi, @naisy. I'm [Dosu](https://dosu.dev), and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that the Ollama plugin (v0.0.7) had a hardcoded 300-second HTTP read timeout causing failures with large models or long prompts. - It was confirmed that changing this timeout required editing plugin code and rebuilding Docker containers. - You proposed and shared a code modification to add configurable connect and read timeout parameters in the plugin UI. - The read_timeout default was set to -1 (no limit) to better support complex workflows with many parallel LLM calls. - This enhancement was positively received and suggested for official adoption. **Next Steps:** - Please confirm if this issue is still relevant to the latest version of the dify-official-plugins repository by commenting here. - If no further updates are provided, I will automatically close this issue in 5 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
bug
dependencies
documentation
enhancement
good first issue
invalid
pull-request
Mirrored from GitHub Pull Request
 question
stale
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-official-plugins#568
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?