OpenAI-API-compatible provider keeps broken Perplexity Sonar credentials and validation fails

[fukayanozomifb4-maker]

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

1.14.1

Cloud or Self Hosted

Cloud

Steps to reproduce

1. Add Perplexity Sonar models using OpenAI-API-compatible provider
2. Delete or modify credentials
3. Try reopening credential configuration
4. Reinstall provider
5. Try adding a new Sonar model

✔️ Expected Behavior

Credentials should delete correctly and deleted models should not reappear after reinstalling the provider.

Validation for newly added Sonar models should succeed with valid max token settings.

❌ Actual Behavior

Using the OpenAI-API-compatible provider with Perplexity Sonar models causes broken credential references.

Deleted credentials cannot be removed because Dify says they are still in use, but opening the credential configuration shows:
"Credential with id xxx not found"

Additionally, reinstalling the provider causes deleted Sonar models to reappear automatically.

Trying to add a new Sonar model with a new credential also fails validation incorrectly with:
"max_tokens must be at least 16 for sonar"

even though max tokens is set properly.

This issue may indicate orphaned credential references remaining in the workspace state after model/provider deletion.

[dosubot]

Hi @fukayanozomifb4-maker! I'm Dosu and I’m helping the dify team.

This matches a confirmed issue that multiple users have reported on Dify 1.14.1. There are actually two separate bugs at play here:

1. Orphaned credential references ("Credential with id xxx not found")

This is caused by a backward-compatibility issue introduced in 1.14.x where legacy model_type values in the database (text-generation, embeddings, reranking) no longer match the new enum values (llm, text-embedding, rerank). The mismatch prevents proper credential lookup, which is why you see "Credential with id xxx not found" and why deleted models reappear after reinstalling the provider [1].

A fix was merged in PR #34717 — but since you're on Dify Cloud, it depends on whether this has been deployed to your environment yet. You may want to check with the Dify team on when this fix will reach Cloud.

2. "max_tokens must be at least 16 for sonar" validation failure

This is a separate bug in the OpenAI-API-compatible plugin. The plugin uses a hardcoded max_tokens: 5 when validating credentials, but Perplexity Sonar requires at minimum 16 tokens. This is tracked in dify-official-plugins#1694 and has been reported by multiple users [2].

Since you're on Dify Cloud, the self-hosted workarounds (SQL updates, manual file edits) are not available to you. I'd recommend reaching out via the Dify Cloud support channels to confirm when PR #34717 and the plugin fix will be deployed. The related issue #36129 tracks the same orphaned credential symptoms on 1.14.1 [1].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[fukayanozomifb4-maker]

@dosu Thanks for the detailed explanation.

Do you know whether PR #34717 has already been deployed to Dify Cloud, or is there any estimated timeline for the Cloud rollout?

[dosubot]

Good question. PR #34717 was merged on April 8, 2026, and the fix is included in Dify 1.14.0 and later (including 1.14.1, which you're on) [1].

This means the application-level fix for the model_type enum deserialization should already be present in Dify Cloud 1.14.1. However, the fact that you're still experiencing the "Credential with id xxx not found" error suggests that existing stale database records from before the fix was deployed were not retroactively migrated — the PR fixes new deserialization but doesn't clean up already-corrupted rows.

In other words, the fix prevents the issue from occurring on fresh configurations, but pre-existing orphaned entries with legacy model_type values may still be stuck in the database. Since you're on Dify Cloud and can't run SQL directly, this likely requires the Dify Cloud team to perform a data migration or cleanup on their end.

I'd suggest flagging this as a Cloud-specific data migration issue — the application fix is deployed, but a one-time database cleanup may still be needed for affected workspaces. The max_tokens validation issue (dify-official-plugins#1694) is a separate plugin-side bug that would need a plugin update from the Dify team regardless.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[crazywoola]

Hi @fukayanozomifb4-maker, thanks for the report.

Could you please add the exact OpenAI-API-compatible provider configuration that is safe to share, the affected Perplexity Sonar model names, and the full validation error returned after deleting or modifying the credentials?

It would also help to know whether deleting and recreating the OpenAI-API-compatible provider entry fully clears the broken credential state, or whether the workspace remains stuck afterward.