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

v1.13.3

Cloud or Self Hosted

Self Hosted (Docker), Self Hosted (Source)

Steps to reproduce

1. Start from an older Dify database that still contains legacy model_type = 'reranking' values.
2. Upgrade to current main and start the API.
3. During startup or when loading model-related records, Dify reads model_type from the database and tries to coerce it into the current ModelType enum.
4. The process fails with:

ValueError: 'reranking' is not a valid ModelType

From local investigation, this appears to happen because current code expects rerank, while older persisted data may still store reranking.

A minimal example is any model-related table row with a legacy model_type value such as reranking, for example in tables like:

- provider_models
- tenant_default_models
- provider_model_settings
- load_balancing_model_configs
- provider_model_credentials

✔️ Expected Behavior

Dify should remain backward-compatible with legacy persisted model type values such as reranking, and normalize them to the current enum value (rerank) instead of crashing during startup or
record loading.

❌ Actual Behavior

Dify crashes with:

  ValueError: 'reranking' is not a valid ModelType

This prevents the service from starting correctly when older database records still contain the legacy enum value.

Additional context

ModelType.value_of() already accepts legacy aliases like reranking -> rerank, but some read paths still appear to use direct enum coercion and fail before normalization can happen.

This looks like a backward-compatibility regression for self-hosted upgrades with existing data.

A robust fix would be either:

1. normalize legacy enum values when reading from the database, and/or
2. add a migration that updates persisted model_type = 'reranking' to rerank.