fix : preserve provider engine type when editing custom providers

[Abhijay007]

Closes: #6046

PR Description

When editing a custom provider in Goose Desktop, the Provider Type dropdown always defaulted to OpenAI Compatible, regardless of the provider’s actual engine (Anthropic or Ollama). Saving the form without reselecting the correct type overwrote the engine to openai, resulting in an incorrect configuration.

This issue was caused by a mismatch between frontend engine values (using _compatible suffixes) and the backend’s expected engine values.

Changes Made

file modified: ui/desktop/src/components/settings/providers/modal/subcomponents/forms/CustomProviderForm.tsx

• Updated engine values to match backend (openai, anthropic, ollama)
• Fixed default engine initialization using initialData.engine
• Removed unnecessary mapping logic in useEffect
• Updated dropdown options and label logic accordingly

file modified: ui/desktop/src/components/settings/providers/ProviderGrid.tsx

• Removed redundant .toLowerCase() call when passing the engine value

Type of Change

• Bug fix

Testing

• Tested in Desktop UI by editing and saving custom OpenAI , Anthropic , and Ollama-based providers

Screenshots / Demos

Before:

After:

[Copilot]

Pull request overview

This PR attempts to fix an issue where the Provider Type dropdown in the custom provider edit form always defaults to "OpenAI Compatible" regardless of the provider's actual engine type. However, the PR introduces critical bugs that will break custom provider creation and updates.

Key Issue

The PR misidentifies the root cause. The backend has an architectural inconsistency:

• Backend returns (via GET /config/custom-providers/{id}): engine: "openai" (lowercase, no suffix)
• Backend expects (via POST/PUT to custom-providers endpoints): engine: "openai_compatible" (with _compatible suffix)

The old code correctly handled this with an engineMap that converted between formats. The PR removes this conversion, causing the frontend to send "openai" when the backend expects "openai_compatible", resulting in "Invalid provider type" errors.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
ui/desktop/src/components/settings/providers/modal/subcomponents/forms/CustomProviderForm.tsx	Removes engine value conversion mapping and changes dropdown options/values to use lowercase format without _compatible suffixes. This breaks API compatibility with the backend's create/update endpoints.
ui/desktop/src/components/settings/providers/ProviderGrid.tsx	Removes redundant .toLowerCase() call when passing engine value (harmless change since values are already lowercase).

[DOsinga]

the description of the PR says that this is due to a mismatch of the backend and the frontend and the _compatible suffix, but what the PR does is remove the toLowercase (which seems reasonable) - is this what you wanted to do?

[Abhijay007]

the description of the PR says that this is due to a mismatch of the backend and the frontend and the _compatible suffix, but what the PR does is remove the toLowercase (which seems reasonable) - is this what you wanted to do?

Oh yes, that was the issue I initially suspected. However, I received a review from Copilot mentioning that this change would break the backend, as the backend would reject it with an “Invalid provider type” error.

I looked into it further and found that the problem was due to a lowercase mismatch, the values were being sent in lowercase, which caused the backend validation to fail. Because of this, I reverted those changes and pushed a fix.

For reference, you can check the Copilot review comments.

[DOsinga]

hmm, not sure I follow still; does the backend use different values from what it sends and what it receives? if that is the case, can't we just fix that in the backend?

[Abhijay007]

hmm, not sure I follow still; does the backend use different values from what it sends and what it receives? if that is the case, can't we just fix that in the backend?

The issue is that the backend expects engine values with the _compatible suffix (for example, openai_compatible, anthropic_compatible, ollama_compatible). The Rust code in crates/goose/src/config/declarative_providers.rs explicitly matches against these exact strings.

If we change these values to openai, anthropic, or ollama, the backend rejects them with an “Invalid provider type” error. So removing the suffix would break the backend.

I revisited the issue and found that the reason the provider was defaulting back incorrectly was not due to the suffix, but because the value was being converted to lowercase, so instead of making changes in the backend (which may have affected other things) I changed the lowercase value conversion. This caused a mismatch, making the backend think it was receiving an invalid engine value. As a result, the UI fell back to showing the engine type from which the custom provider was originally created.

In short, we don’t need to update or remove any suffix values. The fix was simply to remove the lowercase conversion that was causing the mismatch and backend validation error in provider grid and provider form.

[DOsinga]

but can't we change the backend so it accepts this too?

[Abhijay007]

but can't we change the backend so it accepts this too?

I don't think that is needed, as that might affect the backend api response, which might be getting used at other places too, and if we update that for this change, we might need to look into that as well, and the current change will not affect it

[alexhancock]

description seems a bit out of sync with the changes, but the changes look fine to make to me