Legacy model_type values break custom model credential management

[QuantumGhost]

AI disclosure: This issue was drafted and analyzed with Codex using GPT-5.4. I have reviewed the analysis, and I am responsible for the content.

Summary

Custom model credential management breaks for workspaces that still have legacy model_type values in provider-related tables. Requests with canonical query values such as model_type=llm can return Credential with id ... not found, which prevents users from loading, updating, switching, or deleting OpenAI-compatible custom model credentials.

Root cause

The EnumText(ModelType) migration removed legacy query normalization from several read paths while keeping only result deserialization compatibility.

ModelType.value_of("text-generation") still deserializes legacy rows to ModelType.LLM, but SQL bind parameters are emitted as canonical values such as llm. Rows that still store legacy values such as text-generation or embeddings are therefore skipped by read queries.

The regression affects mixed datasets in tables including:

• provider_models
• tenant_default_models
• provider_model_settings
• provider_model_credentials
• load_balancing_model_configs

Reproduction

1. Persist a custom model credential row with provider_model_credentials.model_type = 'text-generation'.
2. Open the custom model credential endpoint with model_type=llm.
3. Observe Credential with id ... not found.

Impact

• Users cannot load, update, switch, or delete affected custom model credentials.
• Available credential lists can appear empty.
• Default model and load balancing lookups can also miss legacy rows.

Proposed fix

Use a shared read-path helper that matches both canonical and legacy model_type values during queries, while keeping new writes on canonical enum values.

[dosubot]

Your analysis is correct. PR #34717 (merged April 8, 2026) fixed the deserialization side — EnumText.process_result_value() now falls back to ModelType.value_of() when direct enum construction fails [1]. However, process_bind_param still emits canonical enum values (e.g., 'llm') for bind parameters [2], and all read-path queries use direct enum equality comparisons like ProviderModelCredential.model_type == model_type [3]. This means rows storing legacy values (text-generation, embeddings, reranking) are indeed skipped by WHERE clauses.

This matches the symptoms reported in #36129 where users on 1.14.x see "Credential with id ... not found" — the credential row exists but the query never matches it [4].

No Alembic migration exists to normalize these values in-place. The current workaround is the manual SQL fix:

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';
-- repeat for provider_model_credentials, tenant_default_models,
-- provider_model_settings, load_balancing_model_configs

Your proposed fix (a shared read-path helper matching both canonical and legacy values) would address the bind-parameter gap that #34717 left open. An alternative — and arguably more complete — approach would be an Alembic data migration that normalizes legacy values at upgrade time, eliminating the mismatch entirely rather than working around it at query time. Both approaches are valid; combining them (migration + defensive read helper) would be the most robust solution for mixed datasets.

Written by @dosu, approved by crazywoola

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.