Self Checks
To make sure we get to you in time, please check the following :)
Versions
- dify-plugin-daemon Version
- dify-api Version
Describe the bug
When a user triggers a plugin downgrade (e.g., from langgenius/openai:0.4.0 to langgenius/openai:0.3.8) through the Dify UI, the upgrade_plugin_with_marketplace method in plugin_service.py fails due to an inconsistency between two database tables in the daemon:
- fetch_plugin_manifest(0.3.8) is called on the daemon
→ The daemon looks up the plugin_declarations table and finds the record (this table is NOT cleaned up during upgrades)
→ Returns success ✅
- Since the manifest exists, the code assumes the package is already available locally
→ Skips the download_plugin_pkg + upload_pkg steps ❌
- upgrade_plugin(0.4.0 → 0.3.8) is called on the daemon directly
→ The daemon queries the plugins table (this record WAS deleted during the previous upgrade when refers dropped to 0)
→ Falls through to the slow path, calls manager.Install()
→ Tries to read the package file from packageBucket → file not found → ERROR ❌
Root cause: The Dify API server uses fetch_plugin_manifest to determine whether a plugin package is already available in the daemon's local storage. However, the plugin_declarations record persists even after the corresponding plugins record and the actual packageBucket file have been removed. These two checks are inconsistent, causing the API server to skip the download-and-upload step for downgrade scenarios.
To Reproduce
Steps to reproduce the behavior:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- 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.
Self Checks
To make sure we get to you in time, please check the following :)
Versions
Describe the bug
When a user triggers a plugin downgrade (e.g., from langgenius/openai:0.4.0 to langgenius/openai:0.3.8) through the Dify UI, the upgrade_plugin_with_marketplace method in plugin_service.py fails due to an inconsistency between two database tables in the daemon:
→ The daemon looks up the plugin_declarations table and finds the record (this table is NOT cleaned up during upgrades)
→ Returns success ✅
→ Skips the download_plugin_pkg + upload_pkg steps ❌
→ The daemon queries the plugins table (this record WAS deleted during the previous upgrade when refers dropped to 0)
→ Falls through to the slow path, calls manager.Install()
→ Tries to read the package file from packageBucket → file not found → ERROR ❌
Root cause: The Dify API server uses fetch_plugin_manifest to determine whether a plugin package is already available in the daemon's local storage. However, the plugin_declarations record persists even after the corresponding plugins record and the actual packageBucket file have been removed. These two checks are inconsistent, causing the API server to skip the download-and-upload step for downgrade scenarios.
To Reproduce
Steps to reproduce the behavior:
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.