dify My plugin fails to run after packaging, but it works fine in debugging.

Self Checks

[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 (我已阅读并同意 Language Policy).
[x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
[x] Please do not modify this template :) and fill in all the required fields.

Dify version

1.1.3

Cloud or Self Hosted

Cloud

Steps to reproduce

Hello! I developed a plugin based on Dify. This plugin can execute successfully in a very short time during debugging, but it fails to execute after being packaged.The following is an example I made temporarily.

I tried to find answers in issues and discussions. There were similar problems, but there were no solutions, so I'm raising this issue.Here is my packaged plugin, which contains multiple tools. I've tested them, and it seems that none of the tools can run properly after packaging, although they do work fine during debugging. This really puzzles me. Out of desperation, I have no choice but to seek help.

auto.zip

I also checked my plugin against the dify-official-plugins repository to identify any critical issues, but I couldn’t find any. I’m at a loss and have no choice but to seek assistance.

If you want to check the GitHub repository of the plugin, here it is.

https://github.com/flower0wine/dify-tools

✔️ Expected Behavior

I expected both plugins to function properly, with the only difference being their state in debug mode versus after packaging. However, the packaged build fails to run, and the plugin code is not being executed.

❌ Actual Behavior

The packaged plugin code is not being executed, and the process runs until it times out.

Apr 07 '25 12:04 flower0wine

你好 @flower0wine！我是一个可以帮助你解决bug、回答问题和成为贡献者的机器人。在你等待人类维护者的同时，我会尽力协助你。期待一起解决你的问题！

I found a similar discussion that might be relevant to your issue: Please help! My plugin fails to run after packaging, but it works fine in debugging. Although it remains unsolved, there is a related closed issue that suggests a solution. The issue indicates that the package might only contain the source code without dependencies, which could be causing the problem.

To address this, ensure you have internet access to install the dependencies. Additionally, you can set up the following environment variables in your docker-compose.yaml file:

PYTHON_ENV_INIT_TIMEOUT: ${PLUGIN_PYTHON_ENV_INIT_TIMEOUT:-120}
PLUGIN_MAX_EXECUTION_TIMEOUT: ${PLUGIN_MAX_EXECUTION_TIMEOUT:-600}
PIP_MIRROR_URL: ${PIP_MIRROR_URL:-}

Switching to a tuna mirror might also help if needed ^[1]^[2].

To continue talking to Dosu, mention @dosu.

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

Apr 07 '25 12:04 dosubot[bot]

@dosu,What could have caused this error?

Failed to transform tool message: PluginInvokeError: {"args":null,"error_type":"PluginDaemonInnerError","message":"failed to read response body: context deadline exceeded"}

Apr 16 '25 07:04 flower0wine

The error "PluginInvokeError: {"args":null,"error_type":"PluginDaemonInnerError","message":"failed to read response body: context deadline exceeded"}" is likely caused by a timeout issue when trying to read the response body from the plugin daemon inner API. This can happen if the request takes longer than the allowed time to complete, possibly due to network latency, server performance issues, or incorrect timeout configuration.

If you are using the Gemini models in Dify v1.1.3, this error might occur due to the API not accepting or saving new Google API keys. A temporary solution is to switch to plugin version 0.0.5 while the Gemini provider is being updated. You can change the plugin version by going to the Plugin page in the top right corner of Dify or by visiting https://cloud.dify.ai/plugins.

Additionally, ensure that your plugin daemon service is properly configured and running. If you are using Docker, verify that the service defined in your docker-compose.middleware.yaml is active ^[1]^[2]^[3].

To continue talking to Dosu, mention @dosu.

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

Apr 16 '25 07:04 dosubot[bot]

@dosu,I'm using a cloud-based service instead of a self-deployed one. Moreover, I was surprised to find that the plugin could run during debugging, but it failed to run after being packaged.

Apr 16 '25 07:04 flower0wine

In cloud-based environments, differences between debugging and packaged states can sometimes lead to issues like the one you're experiencing. During debugging, the environment might be more permissive or have different configurations compared to the packaged state. Here are a few things to consider:

Dependencies: Ensure that all necessary dependencies are correctly specified and available in the packaged environment. During packaging, dependencies might not be included automatically and need to be installed separately ^[1].
Timeout Settings: Check if the timeout settings are appropriate for your plugin's execution time. You can adjust the PLUGIN_MAX_EXECUTION_TIMEOUT and other related timeout settings in your docker-compose.yaml file to ensure that the plugin has enough time to execute ^[2].
Network Configuration: In cloud environments, network configurations might differ between debugging and packaged states. Ensure that any required network access or API keys are correctly configured and accessible in the packaged environment.
Environment Variables: Verify that all necessary environment variables are set correctly in the cloud environment. These might differ from your local debugging setup.

By addressing these areas, you might be able to resolve the issue with your plugin not running after being packaged.

To continue talking to Dosu, mention @dosu.

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

Apr 16 '25 07:04 dosubot[bot]

@dosu,However, it's not that just one specific tool can't run. All the tools within this plugin package are unable to run, which ultimately led to the error mentioned above. My tool code won't be executed either. I also think it might be a problem with the configuration of my plugin. So, I went to check the configurations of other plugins. Unfortunately, I didn't find the cause of the error in my plugin.

Apr 16 '25 07:04 flower0wine

@dosu,However, it's not that just one specific tool can't run. All the tools within this plugin package are unable to run, which ultimately led to the error mentioned above. My tool code won't be executed either. I also think it might be a problem with the configuration of my plugin. So, I went to check the configurations of other plugins. Unfortunately, I didn't find the cause of the error in my plugin.

Apr 16 '25 14:04 flower0wine

Same here, exactly the same.

Apr 25 '25 02:04 fernvenue

Hi, I just found out that the error occurs because the Generator type from typing requires three arguments: Generator[YieldType, SendType, ReturnType]. However, in my code, I only provided one argument (ToolInvokeMessage), which is insufficient.

To fix this, I specified all three arguments for Generator, but the SendType and ReturnType are not used in my generator, so I prefer None for them. Here's the corrected code:

Before:

def _invoke(self, tool_parameters: dict[str, Any]) -> Generator[ToolInvokeMessage]:

After:

def _invoke(self, tool_parameters: dict[str, Any]) -> Generator[ToolInvokeMessage, None, None]:

Now the problem solved, and only god knows why this issue not appear in debugging mode.

Apr 25 '25 03:04 fernvenue

@fernvenue, Oh, my goodness! Thank you for discovering this issue. I really didn't expect it to be such a minor problem. However, it's indeed puzzling to me why there were no issues during debugging.

Apr 25 '25 04:04 flower0wine

I've looked at some of the official plugin examples, and they don't have the last few values either. So why can they run? I added "None", but it still can't run. Brother, please help me! 😂 @fernvenue

Apr 25 '25 07:04 flower0wine

Hi @flower0wine, is your plugin open source? I may can give it a check.

Apr 25 '25 09:04 fernvenue

@fernvenue, Thank you so much for your time and effort. I truly appreciate it. Yes, my code is open-source. this is Dify-Tools

To avoid wasting your precious time, I retested several tools. I found issues when testing the three tools: official_account_tool, baijiahao_tool, and email_tool. However, when testing jimeng_tool and juejin_tool, an internal error of the tools occurred, which indicates that these two tools can be executed normally.

By the way, during the testing process, you may be required to enter various necessary information, such as a cookie string. For a string, you can directly fill in something like "123". I haven't implemented any validation. As long as an internal error of the tool appears,it means the tool can run.

If it keeps running, there might be that mysterious bug we discussed before. I've provided some examples below. You can either directly use the difypkg package I've prepared or package it yourself. I've done my best to save your time. Thank you for your time regardless of the outcome.

This is an example of a tool operation error.

This is an example of filling in parameters for the tool.

This is the difypkg I packaged. Of course, you can also package it by yourself.

dify-tools.zip

Apr 25 '25 10:04 flower0wine

Hi, I just used email_tool from your plugins for testing, and I found that you imported resend at https://github.com/flower0wine/dify-tools/blob/b01501a63c866da9d5539f4ec114caaa38106df2/email_tool/tools/email_sender.py#L1 but this resend doesn't seem to be clearly defined, which leads to the error No module named 'resend'. Also, you haven't listed the corresponding dependencies in the requirements. I think you may need to debug your plugin more before packaging it.

By the way, here's a useful suggestion: make sure to frequently use docker compose logs plugin_daemon to fetch logs from the plugin container, as this will help you better locate errors :)

And I hope you finish your plugins soon, good luck!

Apr 25 '25 12:04 fernvenue

Thank you for your time and suggestions. May I ask if you ran the plugin locally? Since I conducted the test in the cloud, I'm not sure what error messages there might be. @fernvenue

Apr 25 '25 12:04 flower0wine

The reason why the dependencies of the plugin were not provided is that during debugging, I found that even without specifying the dependencies in the requirements.txt file, the plugin could still run normally. This led me to mistakenly believe that these dependencies were already automatically included in the dify runtime environment, which was why the plugin could operate.

Apr 25 '25 12:04 flower0wine

May I ask if you ran the plugin locally? Since I conducted the test in the cloud, I'm not sure what error messages there might be.

Yea, I tested it on my Dify server, and maybe run your own local server will be better, so that you can check the service log directly. By the way, if you wanna publish your plugins to the market, it is required to test both Dify Community Edition and Cloud Version:

I confirm my plugin works properly on both Dify Community Edition and Cloud Version

As https://github.com/langgenius/dify-plugins/blob/main/.github/pull_request_template.md#27 mentioned above.

Apr 25 '25 12:04 fernvenue

OK, thank you, bro. I can finish the rest by myself now. I really appreciate your help!!! @fernvenue

Apr 25 '25 12:04 flower0wine

Thank you so much. It actually worked after I added the dependencies! Before, I thought it would be more convenient to use the cloud platform provided by dify, but it turned out that I wasted so much time in vain. It's really true that the more I tried to save resources, the more resources I wasted. Haha. @fernvenue

Apr 25 '25 12:04 flower0wine