Gemini provider can not add/edit/delete the credentials #826

Closed
opened 2026-02-16 10:20:38 -05:00 by yindo · 6 comments
Owner

Originally created by @Caixiaopig on GitHub (Nov 24, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues Dify issues & Dify Official Plugins, 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.

Dify version

1.10.0

Plugin version

0.6.4

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. Install the Gemini plugin (or reinstall it).

  2. Navigate to "settings" -> "model provider," locate Gemini, and click "Config."

  3. Click "Edit" next to "API_KEY1," which triggers the error: Credential with id 0199d292-3c69-718a-8278-3bcc47d6984a not found.
    Image

  4. Click "Delete" next to "API_KEY1," resulting in the error: Credential record not found.

Image
  1. Click "Add" next to "API_KEY1," fill in the required fields, and a prompt appears stating 'Modified successfully,' yet the addition is not successful.
Image

✔️ Error log

No error logs were found using the docker compose logs -f command

Originally created by @Caixiaopig on GitHub (Nov 24, 2025). ### Self Checks - [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 [Dify issues](https://github.com/langgenius/dify/issues) & [Dify Official Plugins](https://github.com/langgenius/dify-official-plugins/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.10.0 ### Plugin version 0.6.4 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. Install the Gemini plugin (or reinstall it). 2. Navigate to "settings" -> "model provider," locate Gemini, and click "Config." 3. Click "Edit" next to "API_KEY1," which triggers the error: `Credential with id 0199d292-3c69-718a-8278-3bcc47d6984a not found.` <img width="1800" height="1324" alt="Image" src="https://github.com/user-attachments/assets/9d202078-3d96-4887-a759-4e9f2e409d76" /> 5. Click "Delete" next to "API_KEY1," resulting in the error: `Credential record not found.` <img width="1676" height="1144" alt="Image" src="https://github.com/user-attachments/assets/6fecb6cb-d501-4eda-8ed4-35466dd90eca" /> 7. Click "Add" next to "API_KEY1," fill in the required fields, and a prompt appears stating 'Modified successfully,' yet the addition is not successful. <img width="1666" height="1494" alt="Image" src="https://github.com/user-attachments/assets/77be5e5c-72c1-455e-b2bc-5ca96690e653" /> ### ✔️ Error log No error logs were found using the `docker compose logs -f` command
yindo added the bug label 2026-02-16 10:20:38 -05:00
yindo closed this issue 2026-02-16 10:20:38 -05:00
Author
Owner

@Caixiaopig commented on GitHub (Nov 24, 2025):

When I enabled Debug mode, I got the following logs:

api-1            | 2025-11-24 14:12:07.235 INFO [Thread-56 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:12:07] "GET /console/api/workspaces/current/models/model-types/llm HTTP/1.1" 200 -
nginx-1          | 10.18.0.159 - - [24/Nov/2025:14:12:07 +0000] "GET /console/api/workspaces/current/models/model-types/llm HTTP/1.1" 200 281808 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 162.158.99.99"
plugin_daemon-1  | [GIN] 2025/11/24 - 14:12:16 | 200 |   42.005284ms |     172.19.0.10 | GET      "/plugin/9e7bfc6f-4f76-43cf-a597-3016fa07d8a2/management/models?page=1&page_size=256"
api-1            | 2025-11-24 14:12:16.633 INFO [Thread-92 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:12:16] "GET /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials?credential_id=0199d292-3c69-718a-8278-3bcc47d6984a HTTP/1.1" 400 -
nginx-1          | 10.18.0.159 - - [24/Nov/2025:14:12:16 +0000] "GET /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials?credential_id=0199d292-3c69-718a-8278-3bcc47d6984a HTTP/1.1" 400 136 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 172.68.99.99"


api-1            | 2025-11-24 14:13:56.482 INFO [Thread-96 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:13:56] "DELETE /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials HTTP/1.1" 400 -
nginx-1          | 10.18.0.227 - - [24/Nov/2025:14:13:56 +0000] "DELETE /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials HTTP/1.1" 400 98 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 172.71.99.99"
@Caixiaopig commented on GitHub (Nov 24, 2025): When I enabled Debug mode, I got the following logs: ``` api-1 | 2025-11-24 14:12:07.235 INFO [Thread-56 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:12:07] "GET /console/api/workspaces/current/models/model-types/llm HTTP/1.1" 200 - nginx-1 | 10.18.0.159 - - [24/Nov/2025:14:12:07 +0000] "GET /console/api/workspaces/current/models/model-types/llm HTTP/1.1" 200 281808 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 162.158.99.99" plugin_daemon-1 | [GIN] 2025/11/24 - 14:12:16 | 200 | 42.005284ms | 172.19.0.10 | GET "/plugin/9e7bfc6f-4f76-43cf-a597-3016fa07d8a2/management/models?page=1&page_size=256" api-1 | 2025-11-24 14:12:16.633 INFO [Thread-92 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:12:16] "GET /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials?credential_id=0199d292-3c69-718a-8278-3bcc47d6984a HTTP/1.1" 400 - nginx-1 | 10.18.0.159 - - [24/Nov/2025:14:12:16 +0000] "GET /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials?credential_id=0199d292-3c69-718a-8278-3bcc47d6984a HTTP/1.1" 400 136 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 172.68.99.99" api-1 | 2025-11-24 14:13:56.482 INFO [Thread-96 (process_request_thread)] [_internal.py:97] - 172.19.0.11 - - [24/Nov/2025 14:13:56] "DELETE /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials HTTP/1.1" 400 - nginx-1 | 10.18.0.227 - - [24/Nov/2025:14:13:56 +0000] "DELETE /console/api/workspaces/current/model-providers/langgenius/gemini/google/credentials HTTP/1.1" 400 98 "https://xxx.xxx.com/plugins?action=showSettings&tab=provider" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0" "2403:18c0:5:3f5:4c48:8eff:fed4:7243, 172.71.99.99" ```
Author
Owner

@Caixiaopig commented on GitHub (Nov 24, 2025):

I've noticed that when a new Gemini API key is added, the provider_name field in the provider_credentials database table is populated with langgenius/gemini/google. Previously, for newly added records, this field's value was langgenius/google/google.

@Caixiaopig commented on GitHub (Nov 24, 2025): I've noticed that when a new Gemini API key is added, the `provider_name` field in the `provider_credentials` database table is populated with `langgenius/gemini/google`. Previously, for newly added records, this field's value was `langgenius/google/google`.
Author
Owner

@dosubot[bot] commented on GitHub (Nov 24, 2025):

The change in the provider_name field to langgenius/gemini/google is intentional and matches the updated Gemini plugin and backend logic. This new provider namespace is now required for credential lookup and management. If your database still has Gemini credentials with the old provider_name (langgenius/google/google), the backend won't find them, which leads to the "Credential not found" errors when you try to add, edit, or delete keys.

To resolve this, update any existing Gemini credential records in your database to use the new provider_name (langgenius/gemini/google), or remove the old records if they're no longer needed. This will align your data with the current plugin and backend expectations and restore credential management functionality. This change is a result of recent refactors and migration to a new credential system in Dify, which also affected other providers in a similar way (reference).

If you have many records, consider backing up your database before making changes. Keeping your backend, frontend, and plugins in sync after major updates will help avoid similar issues in the future. If you have more questions about the migration or the provider_name field, let me know!

To reply, just mention @dosu.


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

Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 24, 2025): <!-- Answer --> The change in the `provider_name` field to `langgenius/gemini/google` is intentional and matches the updated Gemini plugin and backend logic. This new provider namespace is now required for credential lookup and management. If your database still has Gemini credentials with the old `provider_name` (`langgenius/google/google`), the backend won't find them, which leads to the "Credential not found" errors when you try to add, edit, or delete keys. To resolve this, update any existing Gemini credential records in your database to use the new `provider_name` (`langgenius/gemini/google`), or remove the old records if they're no longer needed. This will align your data with the current plugin and backend expectations and restore credential management functionality. This change is a result of recent refactors and migration to a new credential system in Dify, which also affected other providers in a similar way [(reference)](https://github.com/langgenius/dify-official-plugins/issues/1666). If you have many records, consider backing up your database before making changes. Keeping your backend, frontend, and plugins in sync after major updates will help avoid similar issues in the future. If you have more questions about the migration or the `provider_name` field, let me know! <!-- 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/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=other)</sup> [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20change%20in%20the%20%60provider_name%60%20field%20to%20%60langgenius/gemini/google%60%20is%20intentional%20and%20matches%20the%20updated%20Gemini%20plugin%20and%20backend%20logic.%20This%20new%20provider%20namespace%20is%20now%20required%20for%20credential%20lookup%20and%20management.%20If%20your%20database%20still%20has%20Gemini%20credentials%20with%20the%20old%20%60provider_name%60%20%28%60langgenius/google/google%60%29%2C%20the%20backend%20won%27t%20find%20them%2C%20which%20leads%20to%20the%20%22Credential%20not%20found%22%20errors%20when%20you%20try%20to%20add%2C%20edit%2C%20or%20delete%20keys.%20%0A%0ATo%20resolve%20this%2C%20update%20any%20existing%20Gemini%20credential%20records%20in%20your%20database%20to%20use%20the%20new%20%60provider_name%60%20%28%60langgenius/gemini/google%60%29%2C%20or%20remove%20the%20old%20records%20if%20they%27re%20no%20longer%20needed.%20This%20will%20align%20your%20data%20with%20the%20current%20plugin%20and%20backend%20expectations%20and%20restore%20credential%20management%20functionality.%20This%20change%20is%20a%20result%20of%20recent%20refactors%20and%20migration%20to%20a%20new%20credential%20system%20in%20Dify%2C%20which%20also%20affected%20other%20providers%20in%20a%20similar%20way%20%5B%28reference%29%5D%28https%3A//github.com/langgenius/dify-official-plugins/issues/1666%29.%0A%0AIf%20you%20have%20many%20records%2C%20consider%20backing%20up%20your%20database%20before%20making%20changes.%20Keeping%20your%20backend%2C%20frontend%2C%20and%20plugins%20in%20sync%20after%20major%20updates%20will%20help%20avoid%20similar%20issues%20in%20the%20future.%20If%20you%20have%20more%20questions%20about%20the%20migration%20or%20the%20%60provider_name%60%20field%2C%20let%20me%20know%21)&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-official-plugins/issues/2122)
Author
Owner

@Caixiaopig commented on GitHub (Nov 24, 2025):

The change in the provider_name field to langgenius/gemini/google is intentional and matches the updated Gemini plugin and backend logic. This new provider namespace is now required for credential lookup and management. If your database still has Gemini credentials with the old provider_name (langgenius/google/google), the backend won't find them, which leads to the "Credential not found" errors when you try to add, edit, or delete keys.

To resolve this, update any existing Gemini credential records in your database to use the new provider_name (langgenius/gemini/google), or remove the old records if they're no longer needed. This will align your data with the current plugin and backend expectations and restore credential management functionality. This change is a result of recent refactors and migration to a new credential system in Dify, which also affected other providers in a similar way (reference).

If you have many records, consider backing up your database before making changes. Keeping your backend, frontend, and plugins in sync after major updates will help avoid similar issues in the future. If you have more questions about the migration or the provider_name field, let me know!

To reply, just mention @dosu.

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

Open in Cursor Join Discord Share on X

Thanks!
Is there no other option besides manually updating the database, such as through a migration or a repair program? If a manual database update is indeed necessary, which table fields are involved? I've tried updating the provider_credentials table, but it didn't work, and the error still persists.

@Caixiaopig commented on GitHub (Nov 24, 2025): > The change in the `provider_name` field to `langgenius/gemini/google` is intentional and matches the updated Gemini plugin and backend logic. This new provider namespace is now required for credential lookup and management. If your database still has Gemini credentials with the old `provider_name` (`langgenius/google/google`), the backend won't find them, which leads to the "Credential not found" errors when you try to add, edit, or delete keys. > > To resolve this, update any existing Gemini credential records in your database to use the new `provider_name` (`langgenius/gemini/google`), or remove the old records if they're no longer needed. This will align your data with the current plugin and backend expectations and restore credential management functionality. This change is a result of recent refactors and migration to a new credential system in Dify, which also affected other providers in a similar way [(reference)](https://github.com/langgenius/dify-official-plugins/issues/1666). > > If you have many records, consider backing up your database before making changes. Keeping your backend, frontend, and plugins in sync after major updates will help avoid similar issues in the future. If you have more questions about the migration or the `provider_name` field, let me know! > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3982fe7d-878a-4d98-afa8-aa8c1b3cf0ea?feedback_type=other) > > [<img alt="Open in Cursor" width="120" height="20" src="https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667">](https://cursor.com/link/prompt?text=The%20change%20in%20the%20%60provider_name%60%20field%20to%20%60langgenius/gemini/google%60%20is%20intentional%20and%20matches%20the%20updated%20Gemini%20plugin%20and%20backend%20logic.%20This%20new%20provider%20namespace%20is%20now%20required%20for%20credential%20lookup%20and%20management.%20If%20your%20database%20still%20has%20Gemini%20credentials%20with%20the%20old%20%60provider_name%60%20%28%60langgenius/google/google%60%29%2C%20the%20backend%20won%27t%20find%20them%2C%20which%20leads%20to%20the%20%22Credential%20not%20found%22%20errors%20when%20you%20try%20to%20add%2C%20edit%2C%20or%20delete%20keys.%20%0A%0ATo%20resolve%20this%2C%20update%20any%20existing%20Gemini%20credential%20records%20in%20your%20database%20to%20use%20the%20new%20%60provider_name%60%20%28%60langgenius/gemini/google%60%29%2C%20or%20remove%20the%20old%20records%20if%20they%27re%20no%20longer%20needed.%20This%20will%20align%20your%20data%20with%20the%20current%20plugin%20and%20backend%20expectations%20and%20restore%20credential%20management%20functionality.%20This%20change%20is%20a%20result%20of%20recent%20refactors%20and%20migration%20to%20a%20new%20credential%20system%20in%20Dify%2C%20which%20also%20affected%20other%20providers%20in%20a%20similar%20way%20%5B%28reference%29%5D%28https%3A//github.com/langgenius/dify-official-plugins/issues/1666%29.%0A%0AIf%20you%20have%20many%20records%2C%20consider%20backing%20up%20your%20database%20before%20making%20changes.%20Keeping%20your%20backend%2C%20frontend%2C%20and%20plugins%20in%20sync%20after%20major%20updates%20will%20help%20avoid%20similar%20issues%20in%20the%20future.%20If%20you%20have%20more%20questions%20about%20the%20migration%20or%20the%20%60provider_name%60%20field%2C%20let%20me%20know%21) [<img alt="Join Discord" width="49" height="20" src="https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d">](https://go.dosu.dev/discord-bot) [<img alt="Share on X" width="58" height="20" src="https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b">](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-official-plugins/issues/2122) Thanks! Is there no other option besides manually updating the database, such as through a migration or a repair program? If a manual database update is indeed necessary, which table fields are involved? I've tried updating the `provider_credentials` table, but it didn't work, and the error still persists.
Author
Owner

@dosubot[bot] commented on GitHub (Nov 24, 2025):

There isn’t an official migration or repair tool for this provider_name change, but you don’t need to manually update just the provider_credentials table. The provider_name field is used across multiple tables in Dify, and all of them must be updated for the migration to work. These include: providers, provider_models, provider_orders, tenant_default_models, tenant_preferred_model_providers, provider_model_settings, load_balancing_model_configs, embeddings, and dataset_collection_bindings. If any of these still reference the old provider_name, you’ll keep seeing credential errors source.

Dify does include a migration script (PluginDataMigration in api/services/plugin/data_migration.py) that updates provider_name fields across all relevant tables. You can run this script as part of backend maintenance to automate the migration process. After running it, restart your backend services to clear any credential caches and ensure the changes take effect source.

Always back up your database before making changes. If you want a step-by-step guide for running the migration script, let me know your environment details and I can help with the exact commands.

To reply, just mention @dosu.


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

Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 24, 2025): <!-- Answer --> There isn’t an official migration or repair tool for this provider_name change, but you don’t need to manually update just the provider_credentials table. The provider_name field is used across multiple tables in Dify, and all of them must be updated for the migration to work. These include: providers, provider_models, provider_orders, tenant_default_models, tenant_preferred_model_providers, provider_model_settings, load_balancing_model_configs, embeddings, and dataset_collection_bindings. If any of these still reference the old provider_name, you’ll keep seeing credential errors [source](https://github.com/langgenius/dify/blob/eed38c8b2a89835b6b34d34963995781b36adde0/api/services/plugin/data_migration.py#L13-L212). Dify does include a migration script (`PluginDataMigration` in `api/services/plugin/data_migration.py`) that updates provider_name fields across all relevant tables. You can run this script as part of backend maintenance to automate the migration process. After running it, restart your backend services to clear any credential caches and ensure the changes take effect [source](https://github.com/langgenius/dify/blob/eed38c8b2a89835b6b34d34963995781b36adde0/api/core/provider_manager.py#L42-L886). Always back up your database before making changes. If you want a step-by-step guide for running the migration script, let me know your environment details and I can help with the exact commands. <!-- 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/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3a1c6019-f927-4d00-8a53-4e835064639d?feedback_type=other)</sup> [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=There%20isn%E2%80%99t%20an%20official%20migration%20or%20repair%20tool%20for%20this%20provider_name%20change%2C%20but%20you%20don%E2%80%99t%20need%20to%20manually%20update%20just%20the%20provider_credentials%20table.%20The%20provider_name%20field%20is%20used%20across%20multiple%20tables%20in%20Dify%2C%20and%20all%20of%20them%20must%20be%20updated%20for%20the%20migration%20to%20work.%20These%20include%3A%20providers%2C%20provider_models%2C%20provider_orders%2C%20tenant_default_models%2C%20tenant_preferred_model_providers%2C%20provider_model_settings%2C%20load_balancing_model_configs%2C%20embeddings%2C%20and%20dataset_collection_bindings.%20If%20any%20of%20these%20still%20reference%20the%20old%20provider_name%2C%20you%E2%80%99ll%20keep%20seeing%20credential%20errors%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/eed38c8b2a89835b6b34d34963995781b36adde0/api/services/plugin/data_migration.py%23L13-L212%29.%0A%0ADify%20does%20include%20a%20migration%20script%20%28%60PluginDataMigration%60%20in%20%60api/services/plugin/data_migration.py%60%29%20that%20updates%20provider_name%20fields%20across%20all%20relevant%20tables.%20You%20can%20run%20this%20script%20as%20part%20of%20backend%20maintenance%20to%20automate%20the%20migration%20process.%20After%20running%20it%2C%20restart%20your%20backend%20services%20to%20clear%20any%20credential%20caches%20and%20ensure%20the%20changes%20take%20effect%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/eed38c8b2a89835b6b34d34963995781b36adde0/api/core/provider_manager.py%23L42-L886%29.%0A%0AAlways%20back%20up%20your%20database%20before%20making%20changes.%20If%20you%20want%20a%20step-by-step%20guide%20for%20running%20the%20migration%20script%2C%20let%20me%20know%20your%20environment%20details%20and%20I%20can%20help%20with%20the%20exact%20commands.)&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-official-plugins/issues/2122)
Author
Owner

@Caixiaopig commented on GitHub (Nov 25, 2025):

The issue has been resolved by manually repairing the database.

@Caixiaopig commented on GitHub (Nov 25, 2025): The issue has been resolved by manually repairing the database.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify-official-plugins#826