Stale model configurations persist in db after provider plugin uninstall #16794

Closed
opened 2026-02-21 19:27:38 -05:00 by yindo · 3 comments
Owner

Originally created by @frenoid on GitHub (Sep 5, 2025).

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

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. Install a model provider plugin like Ollama or OpenAI
  2. Add multiple models like llama:3.2, gemma3:27b etc
  3. For each model add a separate configuration for endpoint and token
  4. Uninstall the model provider plugin
  5. Re-install the model provider plugin
  6. See stale configurations added by (3) visible and used by the plugin installed in (5)

✔️ Expected Behavior

After (4) uninstalling the model provider plugin. The database tables provider_models and provider_model_settings should not contain rows referring to the uninstalled provider

After (5) Re-install the model provider plugin, there should be no stale configurations left-over from previous provider installations. The provider is free to accept new model configurations.

Actual Behavior

After (4) uninstalling the model provider plugin. The database tables provider_models and provider_model_settings contains model configurations for the uninstalled model provider.

After (5) Re-install the model provider plugin, stale configurations from previous provider installations are used and visible by the model provider plugin for authentication and model configuration. This causes unexpected authentication issues and buggy plugin behaviour that is difficult to debug.

Originally created by @frenoid on GitHub (Sep 5, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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 [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.8.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. Install a model provider plugin like Ollama or OpenAI 2. Add multiple models like llama:3.2, gemma3:27b etc 3. For each model add a separate configuration for endpoint and token 4. Uninstall the model provider plugin 5. Re-install the model provider plugin 6. See stale configurations added by (3) visible and used by the plugin installed in (5) ### ✔️ Expected Behavior After (4) uninstalling the model provider plugin. The database tables `provider_models` and `provider_model_settings` should not contain rows referring to the uninstalled provider After (5) Re-install the model provider plugin, there should be no stale configurations left-over from previous provider installations. The provider is free to accept new model configurations. ### ❌ Actual Behavior After (4) uninstalling the model provider plugin. The database tables `provider_models` and `provider_model_settings` **contains model configurations for the uninstalled model provider.** After (5) Re-install the model provider plugin, stale configurations from previous provider installations are used and visible by the model provider plugin for authentication and model configuration. This causes unexpected authentication issues and buggy plugin behaviour that is difficult to debug.
yindo added the 🐞 bug label 2026-02-21 19:27:38 -05:00
yindo closed this issue 2026-02-21 19:27:38 -05:00
Author
Owner

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

This is a known limitation in Dify v1.8.1: uninstalling a model provider plugin does not automatically remove related entries from the provider_models or provider_model_settings tables. The uninstall logic only removes the plugin's files and metadata, so stale configurations persist and can cause issues if the plugin is reinstalled. There is currently no built-in cleanup for these tables during plugin uninstall, and recent updates do not address this behavior [source].

To work around this, you can manually delete the stale rows from the relevant tables using SQL. For example:

DELETE FROM provider_models WHERE provider = 'your_provider_name';
DELETE FROM provider_model_settings WHERE provider = 'your_provider_name';

Replace 'your_provider_name' with the actual provider key (e.g., ollama, openai). Always back up your database before running direct SQL commands.

If you want to see this handled automatically, you might consider suggesting it as a feature or following related development for future releases.

To reply, just mention @dosu.


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

@dosubot[bot] commented on GitHub (Sep 5, 2025): <!-- Answer --> This is a known limitation in Dify v1.8.1: uninstalling a model provider plugin does not automatically remove related entries from the `provider_models` or `provider_model_settings` tables. The uninstall logic only removes the plugin's files and metadata, so stale configurations persist and can cause issues if the plugin is reinstalled. There is currently no built-in cleanup for these tables during plugin uninstall, and recent updates do not address this behavior [[source](https://github.com/langgenius/dify/discussions/24895)]. To work around this, you can manually delete the stale rows from the relevant tables using SQL. For example: ```sql DELETE FROM provider_models WHERE provider = 'your_provider_name'; DELETE FROM provider_model_settings WHERE provider = 'your_provider_name'; ``` Replace `'your_provider_name'` with the actual provider key (e.g., `ollama`, `openai`). Always back up your database before running direct SQL commands. If you want to see this handled automatically, you might consider suggesting it as a feature or following related development for future releases. <!-- 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/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1b6a43d8-67c7-4042-a559-6db716209b36?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&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/issues/25266)
Author
Owner

@frenoid commented on GitHub (Sep 5, 2025):

Proposal is to modify the function UninstallPlugin in https://github.com/langgenius/dify-plugin-daemon/blob/b4da677c5e88beeda4a93a6d2295b113dd2223c8/internal/types/models/curd/atomic.go#L173 to delete entries in the provider_models and provider_model_settings database tables.

@frenoid commented on GitHub (Sep 5, 2025): Proposal is to modify the function `UninstallPlugin` in https://github.com/langgenius/dify-plugin-daemon/blob/b4da677c5e88beeda4a93a6d2295b113dd2223c8/internal/types/models/curd/atomic.go#L173 to delete entries in the `provider_models` and `provider_model_settings` database tables.
Author
Owner

@dosubot[bot] commented on GitHub (Oct 6, 2025):

Hi, @frenoid. I'm Dosu (https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that uninstalling a model provider plugin in Dify v1.8.1 leaves stale model configurations in the database.
  • This causes authentication and behavior issues when the plugin is reinstalled.
  • A maintainer confirmed this is a known limitation: uninstall removes plugin files but not database entries.
  • Manual SQL cleanup was suggested as a current workaround.
  • You proposed improving the UninstallPlugin function to automatically delete related database entries during uninstall.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of Dify by commenting here.
  • If I don’t hear back within 15 days, this issue will be automatically closed.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Oct 6, 2025): Hi, @frenoid. I'm Dosu (https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that uninstalling a model provider plugin in Dify v1.8.1 leaves stale model configurations in the database. - This causes authentication and behavior issues when the plugin is reinstalled. - A maintainer confirmed this is a known limitation: uninstall removes plugin files but not database entries. - Manual SQL cleanup was suggested as a current workaround. - You proposed improving the UninstallPlugin function to automatically delete related database entries during uninstall. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of Dify by commenting here. - If I don’t hear back within 15 days, this issue will be automatically closed. Thank you for your understanding and contribution!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#16794