OpenAI-API-Compatible Plugin Broken After Upgrading to v1.14.2 — Can This SQL Fix Work?

[6mvp6]

Self Checks

• I have searched for existing issues search for existing issues, 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.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I upgraded Dify from v1.13.3 to v1.14.2 (self-hosted, Docker deployment), and the OpenAI-API-compatible plugin (v0.0.47 → v0.0.53) became partially unusable:

• Model credentials are invisible in the console under Settings → Model Providers → OpenAI-API-compatible. I can't see or edit existing credentials.
• Cannot delete old credentials through the UI.
• Adding or editing credentials triggers a Pydantic validation error: model_type Field required.
• However, existing Chatflow workflows continue to work — models already configured in nodes still respond normally.

It was frustrating because the plugin was working perfectly before the upgrade, and the errors gave no clear indication that the underlying cause was a model_type column value mismatch in the database.

Root Cause

v1.14.0 refactored the model_type column from a free-form string to EnumText(ModelType) (a typed enum). The ORM layer (EnumText in api/models/types.py) transparently maps legacy values when reading, but writes and queries only use the new enum values:

Legacy value (stored in DB)	New value (code expects)
text-generation	llm
embeddings	text-embedding
reranking	rerank

This creates a read/write asymmetry:

• Read path (process_result_value): Legacy values are correctly mapped via ModelType.value_of() fallback — this is why Chatflow still works.
• Write/query path (process_bind_param): Only new values are used — WHERE model_type = 'llm' does not match rows storing 'text-generation'. This is why the console cannot find or manage old credentials.

Additionally, the tenant_default_models table has a unique constraint on (tenant_id, model_type). After the upgrade, both legacy and canonical rows can coexist (since 'text-generation' ≠ 'llm' at the DB level), creating logical duplicates that violate the application's expectations.

Affected Tables

5 tables store model_type and are affected:

1. provider_model_credentials
2. provider_models
3. provider_model_settings
4. load_balancing_model_configs
5. tenant_default_models

Official Migration Not Available in v1.14.2

The official migration command flask data-migrate legacy-model-types was introduced in PR #36520 (merged May 27), which is after the v1.14.2 release (May 19). So v1.14.2 does not include this command.

2. Additional context or comments

Proposed Fix — Manual SQL Migration

I'd like to confirm whether the following manual SQL migration is safe and correct for fixing this issue. It has been verified on a self-hosted single-tenant instance. I've already backed up the affected tables before proceeding.

Pre-check: Verify provider_models Has No Unique Constraint Conflicts

SELECT pm1.tenant_id, pm1.provider_name, pm1.model_name,
       pm1.model_type AS legacy_type,
       pm2.model_type AS canonical_type
FROM provider_models pm1
JOIN provider_models pm2
  ON pm1.tenant_id = pm2.tenant_id
 AND pm1.provider_name = pm2.provider_name
 AND pm1.model_name = pm2.model_name
 AND pm2.model_type = CASE pm1.model_type
       WHEN 'text-generation' THEN 'llm'
       WHEN 'embeddings' THEN 'text-embedding'
       WHEN 'reranking' THEN 'rerank'
     END
WHERE pm1.model_type IN ('text-generation', 'embeddings', 'reranking');

• Returns 0 rows: No conflicts, proceed with direct UPDATE.
• Returns non-empty: provider_models also needs the two-step approach (DELETE conflicting rows first, then UPDATE).

Migration SQL

BEGIN;

-- 1. provider_model_credentials (no unique constraint on model_type, safe to UPDATE directly)
UPDATE provider_model_credentials SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_model_credentials SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_model_credentials SET model_type = 'rerank' WHERE model_type = 'reranking';

-- 2. provider_models (pre-check confirmed no conflicts, safe to UPDATE directly)
UPDATE provider_models SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_models SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_models SET model_type = 'rerank' WHERE model_type = 'reranking';

-- 3. provider_model_settings (no unique constraint on model_type, safe to UPDATE directly)
UPDATE provider_model_settings SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_model_settings SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_model_settings SET model_type = 'rerank' WHERE model_type = 'reranking';

-- 4. load_balancing_model_configs (no unique constraint on model_type, safe to UPDATE directly)
UPDATE load_balancing_model_configs SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE load_balancing_model_configs SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE load_balancing_model_configs SET model_type = 'rerank' WHERE model_type = 'reranking';

-- 5. tenant_default_models (unique constraint on tenant_id + model_type)
--    Two-step approach: DELETE conflicting legacy rows, then UPDATE remaining legacy rows

-- Step A: Delete legacy rows that have a corresponding canonical row (keep the canonical row)
DELETE FROM tenant_default_models
WHERE model_type IN ('text-generation', 'embeddings', 'reranking')
  AND EXISTS (
    SELECT 1 FROM tenant_default_models t2
    WHERE t2.tenant_id = tenant_default_models.tenant_id
      AND t2.model_type = CASE tenant_default_models.model_type
          WHEN 'text-generation' THEN 'llm'
          WHEN 'embeddings' THEN 'text-embedding'
          WHEN 'reranking' THEN 'rerank'
        END
  );

-- Step B: UPDATE remaining legacy rows (those without a canonical counterpart)
UPDATE tenant_default_models SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE tenant_default_models SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE tenant_default_models SET model_type = 'rerank' WHERE model_type = 'reranking';

COMMIT;

Key design decisions:

• Tables 1–4: Direct UPDATE is safe because they have no unique constraint involving model_type alone.
• Table 5 (tenant_default_models): Requires a two-step approach due to the unique_tenant_default_model_type constraint on (tenant_id, model_type). Step A deletes legacy rows that have a corresponding canonical row (keeping the canonical row). Step B updates remaining legacy rows that have no canonical counterpart.
• All changes are wrapped in a single transaction (BEGIN/COMMIT) for atomicity.

Verification Query

SELECT 'provider_model_credentials' AS tbl, model_type, COUNT(*) FROM provider_model_credentials GROUP BY model_type
UNION ALL
SELECT 'provider_models', model_type, COUNT(*) FROM provider_models GROUP BY model_type
UNION ALL
SELECT 'provider_model_settings', model_type, COUNT(*) FROM provider_model_settings GROUP BY model_type
UNION ALL
SELECT 'load_balancing_model_configs', model_type, COUNT(*) FROM load_balancing_model_configs GROUP BY model_type
UNION ALL
SELECT 'tenant_default_models', model_type, COUNT(*) FROM tenant_default_models GROUP BY model_type
ORDER BY 1, 2;

Expected result: No text-generation, embeddings, or reranking values should remain.

Questions for the Community / Maintainers

1. Is this SQL migration approach correct and safe? Does it align with what the official flask data-migrate legacy-model-types command does internally?
2. Are there any other tables or JSON fields that might also store legacy model_type values that we need to handle?
3. Will this manual migration conflict with the official migration command if we upgrade to a future version that includes PR feat(api): introduce model-type migration script #36520?

Relevant Commits / PRs

Reference	Description
PR #36520	Official migration script flask data-migrate legacy-model-types (not included in v1.14.2)
#34717	Fix: legacy model_type deserialization regression
#34300	Refactor: use EnumText for model_type in provider models
#34093	Refactor: use EnumText for model_type and WorkflowNodeExecution.status

Environment

• Dify version: v1.14.2 (upgraded from v1.13.3)
• Deployment: Docker Compose, self-hosted
• Database: PostgreSQL 15
• Plugin: OpenAI-API-compatible v0.0.53

[6mvp6]

I deleted the old model credentials, and now I can add new model credentials.

[dosubot[bot]]

Your analysis is excellent and your SQL migration is correct and safe for a single-tenant instance. Here's confirmation on your three questions:

1. Is the SQL migration correct and safe?

Yes. Your approach covers the same 5 tables and the same 3 value mappings that the official flask data-migrate legacy-model-types command targets . Your handling of tenant_default_models with the two-step DELETE-then-UPDATE approach to respect the unique constraint is sound.

One difference: the official migration is more sophisticated — it groups rows by business key (e.g., tenant_id + provider_name + model_name + model_type), selects a "winner" based on updated_at timestamp, deletes "loser" duplicates, and rewrites credential_id references in related tables . Your simpler UPDATE approach works well if you don't have conflicting duplicates (which your pre-check query verifies), but it won't handle the credential reference rewriting that the official command does during deduplication.

2. Are there other tables or JSON fields?

Based on the official migration, these are the only 5 tables with model_type columns that need updating. No additional JSON fields storing legacy values were identified .

3. Will this conflict with the official migration later?

No. The official migration is fully idempotent — it only selects rows where model_type is one of the legacy values (text-generation, embeddings, reranking). After your manual UPDATE converts those values to canonical ones, the official command will simply find 0 matching rows and complete without changes . It's safe to run it again after upgrading.

Multiple other users have applied similar SQL fixes successfully for this same issue [1] [2] [3].

Summary: Back up, run your SQL, verify with your verification query, and you're good. When you eventually upgrade to a version that includes PR #36520, the official migration will be a no-op since the values are already normalized.

Written by @dosu, approved by crazywoola

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.