mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
Gemini provider can not add/edit/delete the credentials #826
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Caixiaopig on GitHub (Nov 24, 2025).
Self Checks
Dify version
1.10.0
Plugin version
0.6.4
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
Install the Gemini plugin (or reinstall it).
Navigate to "settings" -> "model provider," locate Gemini, and click "Config."
Click "Edit" next to "API_KEY1," which triggers the error:

Credential with id 0199d292-3c69-718a-8278-3bcc47d6984a not found.Click "Delete" next to "API_KEY1," resulting in the error:
Credential record not found.✔️ Error log
No error logs were found using the
docker compose logs -fcommand@Caixiaopig commented on GitHub (Nov 24, 2025):
When I enabled Debug mode, I got the following logs:
@Caixiaopig commented on GitHub (Nov 24, 2025):
I've noticed that when a new Gemini API key is added, the
provider_namefield in theprovider_credentialsdatabase table is populated withlanggenius/gemini/google. Previously, for newly added records, this field's value waslanggenius/google/google.@dosubot[bot] commented on GitHub (Nov 24, 2025):
The change in the
provider_namefield tolanggenius/gemini/googleis 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 oldprovider_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_namefield, let me know!To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@Caixiaopig commented on GitHub (Nov 24, 2025):
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_credentialstable, but it didn't work, and the error still persists.@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 (
PluginDataMigrationinapi/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
@Caixiaopig commented on GitHub (Nov 25, 2025):
The issue has been resolved by manually repairing the database.