plugin daemon error

[Zz-lo]

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.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

After reinstalling the plugin, it worked. After configuring the credentials, the issue of the model not existing occurred. Then I tried restarting, and the problem of "no available node, plugin runtime not found" appeared again. Below is the error message about the model not existing that occurred when I called it after reinstalling the plugin:

✔️ Expected Behavior

I hope the plugin can work properly.

❌ Actual Behavior

In fact, the model cannot be invoked.

[dosubot]

This "no available node, plugin runtime not found" error means the plugin daemon can't locate the runtime for your installed plugin. This is a recurring issue that typically happens when plugin installation gets into a broken state. Based on a nearly identical resolved issue, here's how to fix it:

1. Check if the plugin exists in the plugin daemon storage — attach to the plugin_daemon container and look in /app/storage/plugin/ for your plugin files. If they're missing, the plugin installation is broken.

2. Clean up and reinstall:

   • Connect to the dify_plugin database and find/delete the broken plugin installation record:

     SELECT * FROM plugin_installations;
     -- Delete the broken entry
     DELETE FROM plugin_installations WHERE plugin_unique_identifier LIKE '%your_plugin%';

   • Reinstall the plugin from the Dify web UI.

3. After reinstalling, if you get "model not existing" errors when configuring credentials, try these additional steps:

   • Increase PYTHON_ENV_INIT_TIMEOUT (e.g., 320) and PLUGIN_MAX_EXECUTION_TIMEOUT (e.g., 2400) in your .env or docker-compose.yaml for the plugin_daemon service — the plugin runtime may be timing out during environment initialization.
   • If you're in an offline/restricted network environment, set PIP_MIRROR_URL so plugin_daemon can install Python dependencies.
   • Restart all containers after changes: docker compose down && docker compose up -d

4. To prevent recurrence after restarts: make sure your Docker volumes are persistent and not being recreated on restart. If you migrated volumes, use tar (not zip) to avoid breaking Python virtualenv symlinks in the plugin daemon storage.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[Zz-lo]

If I upgrade to the latest version of Dify, will that solve this problem?

“找不到可用节点，找不到插件运行时”错误表示插件守护进程无法找到已安装插件的运行时。这是一个常见问题，通常发生在插件安装出现故障时。根据一个几乎相同的已解决问题，以下是解决方法：

1. 检查插件是否存在于插件守护进程存储中——连接到plugin_daemon容器并查找/app/storage/plugin/插件文件。如果找不到，则说明插件安装失败。

2. 清理并重新安装：

   • 连接到dify_plugin数据库并查找/删除损坏的插件安装记录：
     SELECT * FROM plugin_installations;
     -- Delete the broken entry
     DELETE FROM plugin_installations WHERE plugin_unique_identifier LIKE '%your_plugin%';
   • 从 Dify 网页界面重新安装插件。

3. 重新安装后，如果在配置凭据时出现“模型不存在”错误，请尝试以下步骤：

   • 增加您的插件守护进程服务中的PYTHON_ENV_INIT_TIMEOUT（例如，320）和PLUGIN_MAX_EXECUTION_TIMEOUT（例如，2400）——插件运行时可能在环境初始化期间超时。.env``docker-compose.yaml
   • 如果您处于离线/受限网络环境中，请进行设置PIP_MIRROR_URL，以便 plugin_daemon 可以安装 Python 依赖项。
   • 更改后重启所有容器：docker compose down && docker compose up -d

4. 为防止重启后问题再次出现：请确保您的 Docker 卷是持久化的，并且不会在重启时重新创建。如果您迁移了卷，请使用tar（而不是zip）以避免破坏插件守护进程存储中的 Python virtualenv 符号链接。

回复时只需提及@dosu即可。

我做得怎么样？好|无关|错误|冗长|幻觉|举报 🐛 |其他    

[dosubot]

Yes, upgrading should help. Dify 1.11.0 shipped with plugin daemon version 0.5.1-local, which has this issue. Later releases include updated plugin daemon versions (up to 0.5.6-local and beyond) that specifically address the "no available node, plugin runtime not found" error [1]. Several PRs after 1.11.0 also improved plugin daemon error handling and stability [2] [3].

After upgrading, if the issue still persists, try the cleanup steps from my previous message (especially clearing the broken plugin installation records and reinstalling). You may also want to set PYTHON_ENV_INIT_TIMEOUT=720 in your .env to give the plugin runtime more time to initialize [4].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[Zz-lo]

[@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link)I reinstalled a plugin, and a new problem has appeared.

[Zz-lo]

@dosu

[fatelei]

how about your dify-plugin-daemon version? in the stacktrace plugin_manager/local_runtime/stdio.go has been removed in latest branch

[fatelei]

you'd better upgrade dify-plugin-daemon to 0.5.3-local

[dosubot]

@Zz-lo This "no available node, plugin runtime not found" error has been reported by several users. Here are the most likely causes and fixes for your situation (Dify 1.11.1, self-hosted Docker):

1. Check your plugin daemon version and configuration

Since v0.5.2, a configuration value must match the daemon version exactly. If there's a mismatch, you'll get this error even though plugins appear installed. Also, if you're running v0.5.4-local, there are confirmed regressions — consider downgrading to 0.5.3-local:

plugin_daemon:
    image: langgenius/dify-plugin-daemon:0.5.3-local

2. Clean up stale state

Once plugin runtime state becomes inconsistent, the daemon has no automatic recovery mechanism [1]. If restarting alone doesn't fix it, you may need to:

• Check database state: SELECT * FROM plugin_installations; SELECT * FROM plugins; [2]
• Clear Redis cache entries for stale plugin keys
• Clean your plugin storage directory (backup first), then reinstall plugins

3. Verify environment configuration

Make sure PLUGIN_DAEMON_URL uses the service name (e.g., http://plugin_daemon:5003, not localhost), and that your storage paths (PLUGIN_STORAGE_LOCAL_ROOT, PLUGIN_WORKING_PATH, PLUGIN_INSTALLED_PATH) match your Docker volume mounts.

Quickest recovery path: Try docker-compose down && docker-compose up -d first. If the error persists, clean the database records and Redis cache as described above, then reinstall your plugins.

Could you share:

1. Which plugin daemon image version you're using?
2. Your plugin_daemon container logs from startup?

That would help narrow down the specific cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}