remote debug plugin id not match

[fatelei]

Self Checks

To make sure we get to you in time, please check the following :)

• I have searched for existing issues search for existing issues, 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."

Versions

1. dify-plugin-daemon Version
2. dify-api Version

Describe the bug
dify page

query sql in dify-plugin-daemon

SELECT * FROM "plugin_installations" WHERE tenant_id = '1f65992e-48b0-4bdd-8c66-bb74bfc073ce' AND plugin_id = 'langgenius/agent' ORDER BY "plugin_installations"."id" LIMIT 1；

dify plugin table records

the plugin id is mismatch

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[dosubot]

The plugin ID mismatch during remote debug is a known issue and usually comes down to a format discrepancy between the plugin_id used in your SQL queries and the one stored in the database. For example, the daemon or debug workflow might use a tenant-prefixed plugin_id (like tenant_id/plugin_name), while the database stores just plugin_name or org/plugin_name—this causes queries to return no results and triggers errors like PluginNotFoundError. You can see a direct example and explanation of this mismatch here.

Remote debug plugins also use a custom identification mechanism: the daemon may set the tenant ID as the "author" in the plugin unique identifier to flag debugging plugins, which can further complicate matching if the database record doesn't use the same format. The code responsible for this is in the RemotePluginRuntime struct and its Identity() method, which builds the identifier using the tenant ID and plugin config source.

To resolve this, make sure the plugin_id in your database matches exactly what the daemon expects and uses in queries. If you see a mismatch (for example, langgenius/agent vs. tenant_id/langgenius/agent), adjust either the database record or the query construction logic so they align. Also, double-check your manifest.yaml for required fields and formatting, and ensure version numbers match between your plugin and the daemon—version mismatches can also cause "plugin not found" errors even if the plugin appears in the UI details.

If you're running in a multi-pod Kubernetes setup, be aware that plugin runtime registration is not synchronized across pods, so only the pod that registered the plugin can serve requests. This can also cause "plugin not found" errors unless you use a single replica or implement distributed locking details.

In summary: check for plugin_id format mismatches, version alignment, manifest correctness, and deployment topology. If the problem persists, review the plugin daemon logs for more details on how the plugin_id is being constructed and queried.

To reply, just mention @dosu.

---

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