mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
"Can't add same credential" when adding new model provider in a offline environment #607
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 @hagemon on GitHub (Sep 1, 2025).
Self Checks
Dify version
1.8.0
Plugin version
vllm 0.1.5, OpenAI-API-compatible 0.0.22
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
Background
I first cloned and started the Dify service in an environment with internet access.
Then I downloaded the model provider plugins I wanted to use, including vllm and OpenAI-API-compatible.
After that, I copied the entire
volumesfolder into my target intranet (air-gapped) environment.In the intranet environment, Dify can be started successfully, and the models can be "" in both vllm and OpenAI-API-compatible plugins. However, I still encountered some issues.
Problem Description
When I click "Add Model" on the right side and select the one I just added, a popup shows:
"Can't add same credential"
But in fact, I only added this one model.
Related Screenshots
Special Context
I am deploying Dify in a fully isolated intranet environment (no internet access).
Not sure if this situation may have an impact.
Looking forward to your help, thanks a lot!
✔️ Error log
@dosubot[bot] commented on GitHub (Sep 1, 2025):
Hi @hagemon! I'm Dosu and I’m helping the dify-official-plugins team.
Your issue is caused by a recent change in Dify's credential management: in offline (air-gapped) environments, the new credential and model tables require a manual data migration step. When running migrations in offline mode, Dify skips automatic migration of provider credentials and models, so if you haven't manually run the migration functions, the backend may think the credential already exists (even if the UI shows none), resulting in the "Can't add same credential" error and missing models in the UI. This is confirmed by the recent PRs that introduced multi-model credential support and offline migration compatibility fixes—manual execution of migration scripts is now required in air-gapped setups to properly initialize credential and model data [PR #24795] [PR #24451].
To resolve this, manually run the migration functions (like
migrate_existing_providers_dataandmigrate_existing_provider_models_data) in the relevant Alembic migration scripts inside your offline environment. This should sync your credential/model data and allow you to add models and credentials as expected.The plugin daemon's panic (nil pointer dereference) is likely a separate bug triggered by missing or improperly migrated data in offline mode, but fixing the migration should resolve both symptoms.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
I tried some commands, for example:
but it still didn’t work (maybe because this command is unrelated to my issue).
I also tried:
but it returned:
In addition, I tried to look for the
migrate_existing_providers_dataandmigrate_existing_provider_models_datafunctions, but I couldn’t find them. Where can I locate the Alembic migration scripts?By the way, I’m actually using version 1.8.0, and I downloaded and copied the volumes directly in this version, so it seems there shouldn’t be any old data in my setup.
@dosubot[bot] commented on GitHub (Sep 2, 2025):
The migration functions you’re looking for—
migrate_existing_providers_dataandmigrate_existing_provider_models_data—are defined directly inside the Alembic migration scripts in your Dify install:api/migrations/versions/2025_08_09_1553-e8446f481c1e_add_provider_credential_pool_support.pyapi/migrations/versions/2025_08_13_1605-0e154742a5fa_add_provider_model_multi_credential.pyYou can open these files to see the full function definitions and logic for migrating provider and model credential data [source].
The error you hit (
AttributeError: 'NoneType' object has no attribute 'fetchall') happens because Alembic’s--sql(offline mode) disables all database IO, soop.get_bind()returnsNoneand any DB query fails. These migration scripts require a live DB connection and must be run in an online Python context (like a Flask shell or Alembic online mode) inside your Docker container—not with--sqlor Alembic offline mode [source].To fix your credential/model issue, you need to manually run these migration functions in a live Python shell with DB access. For example, inside your API container:
Then, in the shell, import and run the migration functions from the relevant migration script files. This will sync your credential/model data and resolve the “Can't add same credential” error.
If you need more detailed steps for running these migrations manually, let me know!
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
Please give me more detailed steps for running these migrations manually.
@dosubot[bot] commented on GitHub (Sep 2, 2025):
Here are the detailed steps to manually run the required migration functions in your Dify Docker environment:
Enter your API container and start a Flask shell:
In the Flask shell, use Python's importlib to load and run the migration functions:
Watch for errors in the shell output. If both functions run without exceptions, the migration is complete.
Restart your Dify containers to ensure the UI and backend pick up the changes:
Verify in the UI that your models and credentials now appear and you can add new ones without the "Can't add same credential" error.
These steps use the actual migration scripts and functions as defined in your Dify install, and ensure the migrations run with a live DB connection as required for offline environments. For reference, see the migration script source and PR #24795.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
Both function shows
@dosubot[bot] commented on GitHub (Sep 2, 2025):
The error happens because the migration functions use Alembic's
op.get_bind(), which only works inside an Alembic migration run—not in a Flask shell or standalone Python script. To run these migrations manually in your offline Docker environment, you need to adapt the migration logic to use a direct SQLAlchemy connection from your Flask app instead of Alembic'sopobject.Here's how you can do it:
Start a Flask shell inside your API container:
In the shell, run a script like this (adjust paths if needed):
You can adapt the same pattern for the
provider_modelsmigration by copying the logic from the Alembic script and replacingop.get_bind()withdb.engine.connect().Important: Always back up your database before running manual migration scripts. Test in a non-production environment if possible.
This approach directly uses SQLAlchemy and your Flask app's DB connection, bypassing Alembic's migration context and avoiding the
get_binderror. For reference, see the migration logic in the original Alembic script.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
After executing the script, I found that table "providers" does not have column named "encrypted_config".
I checked the columns by the following code:
while the outputs are:
@dosubot[bot] commented on GitHub (Sep 2, 2025):
The reason your script failed is because the
encrypted_configcolumn was intentionally removed from theproviderstable as part of Dify's recent migration to a multi-credential architecture. All provider credential data is now stored in theprovider_credentialstable, and theproviderstable just links to it via thecredential_idcolumn (details, migration PR). This matches your current schema and is expected.Because of this, the migration scripts (and any manual scripts based on them) that reference
providers.encrypted_configwill not work if your database was initialized after the migration—there is no data to migrate, and the column doesn't exist.What to do now:
You should directly manage credentials using the current schema. To add a provider credential, insert a row into
provider_credentials(with your config inencrypted_config), then set thecredential_idfield in the relevantprovidersrow to point to your new credential. You can do this using SQLAlchemy in a Flask shell or with direct SQL. The same pattern applies for model credentials with theprovider_model_credentialsandprovider_modelstables.If you want a code example or step-by-step for this, let me know what provider/model you want to add and I can help you craft the exact commands.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
give me a code example and steps to directly insert a vllm model provider into provider_credentials, you can use some example credential information, and I will replace them with my own.
@dosubot[bot] commented on GitHub (Sep 2, 2025):
Here’s how you can directly insert a vllm provider credential into the provider_credentials table and link it to your vllm provider using SQLAlchemy in the Flask shell:
Start the Flask shell in your API container:
In the shell, run the following Python code (replace the example values with your real API key, endpoint, etc.):
Restart your Dify containers:
Check the Dify UI: Your vllm credential should now appear and be usable.
Notes:
This approach matches the current Dify schema and credential management logic (reference).
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@hagemon commented on GitHub (Sep 2, 2025):
@dosu
returns empty, but in Settings → Model Provider I can see the providers I added (
vllmandopenai-api-compatible), although they both show 0 models.Could this be because I downloaded the plugins in an external environment and then copied the
volumesfolder directly into my isolated intranet environment?@dosubot[bot] commented on GitHub (Sep 2, 2025):
Yes, this is very likely the cause. Copying only the
volumesfolder (which contains plugin files and configs) from an online environment does not migrate your database state—including tenants, provider linkage, and model records. In Dify, providers and credentials are linked to tenants in the database schema, and the backend expects tenant records for normal operation. If the tenants table is empty, providers may still appear in the UI (because their records exist), but they aren't properly linked, so you see "0 models" and can't add credentials or models as expected [source].To fix this, you need to manually create a tenant in your database and update your providers and credentials to reference the new tenant_id. This will restore proper linkage and allow the UI and backend to function correctly. Copying plugin files alone isn't enough; the database must be migrated or reconstructed for full functionality [source].
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@qiulang commented on GitHub (Sep 7, 2025):
I have the same problem and I remember 1.7.2 can work.
@hagemon commented on GitHub (Sep 7, 2025):
solved by using https://github.com/junjiem/dify-plugin-repackaging
@qiulang commented on GitHub (Sep 7, 2025):
@hagemon can you explain how do you fix it? For example, first still download vllm 0.1.5 and use that tool to repackage or something else ? I am not familiar with that tool. Thanks!
@hagemon commented on GitHub (Sep 7, 2025):
@qiulang
In online machine
Clone dify-plugin-repackaging
Download plugin
Download
yangyaofei-vllm_0.1.5.difypkgfile from market.Set up environment
Get offline package
Then copy
yangyaofei-vllm_0.1.5-offline.difypkgto your offline machineIn offline machine
Just choose something like
install from local filein your dify plugin page, all done!@qiulang commented on GitHub (Sep 8, 2025):
@hagemon I did all you said then finally "req_id: 75afd1ccb0 PluginDaemonBadRequestError: plugin verification has been enabled, and the plugin you want to install has a bad signature".
Can't find the place to disable the plugin verification
@hagemon commented on GitHub (Sep 8, 2025):
Forgot an important step.
Edit
.envfile indify/docker:Then restart dify containers.
@qiulang commented on GitHub (Sep 8, 2025):
Okay even I turn off
FORCE_VERIFYING_SIGNATUREin .env and restart the docker, I still failed to add model with the error@hagemon commented on GitHub (Sep 8, 2025):
The problem might be related to the authorization name, model name, or URL configuration.
@qiulang commented on GitHub (Sep 8, 2025):
@hagemon I finally find out it is because the model name has to be the same as the model id.
Now I added my model finally! Thanks!!
BTW why does dify-plugin-repackaging fix the problem ?
@hagemon commented on GitHub (Sep 8, 2025):
@qiulang
You can check the plugin daemon logs and also unzip the difypkg to examine its internal structure.
During the process of uploading a
difypkgdownloaded from the store, Dify will attempt to download the packages listed in therequirements.txtfile inside thedifypkgand build a runtime environment. This step requires internet access.However,
dify-plugin-repackagingdownloads the dependencies for you and places them into the wheels folder, which allows Dify to detect that they are already available and skip any additional downloads.@qiulang commented on GitHub (Sep 8, 2025):
Thanks for the explanation but why does vllm plugin fails to work for 1.8.x in the first place ?
I remember it works for 1.6.x, not sure about 1.7.x