Unable to change assistant model, when current not available

I came across this issue when testing the AI dev recipe which defaults to use "openai" even if you don't have a valid API key, which was causing me issues updating the form.

There seem to be a couple of scenarios you are unable to update the provider:

Scenario 1. The provider stored on the AI assistant is not configured properly
1. Create an AI assistant and choose a provider that is configured correctly
2. Break the provider configuration (ie, change the port to make the models unavailable)
3. Edit the AI assistant
Expected: Able to update AI assistant to a different provider
Actual: Unable to update AI assistant - models is empty and required with "Ollama" remaining selected

Scenario 2. The provider/model stored on the AI assistant has been removed
1. Create an AI assistant and choose a provider that is configured correctly
2. Remove the provider/break the provider by removing the API key
3. Edit the AI assistant
Expected: Able to update AI assistant to a different provider
Actual: Unable to update AI assistant - providers is empty and models won't load

My proposal would be to add some conditional checks/validation and add some helpful error messages that allow changing provider.

If the assistant is using a provider that is no longer available:

If no models are available, the models form does not load and gives an error:

I need to test some more scenarios, and ensure all areas are covered. This caught me off-guard and prevented me testing the assistant functionality so thanks for raising this, along with my issue with "openai" not being available hopefully this UX fix will work.

My main concern is that the form helper where we are giving the models warning is used in many places, but that may be useful for other parts of this module's ecosystem too.

Rebasing and since the MR is on 1.2.x, I'll change to that but set issues tags.

Added some review comments. I think we should also add the tests to check that the fix is working.

Let's see what it needs.

Thank You for the changes and testing so far.

I added a new commit with some improvements that will:

* Pre-validate provider/model before form generation to prevent exceptions
* Validate models in AJAX callbacks to catch invalid selections immediately
* Add error logging for provider failures (logged to 'ai' channel)
* Show generic user-facing error messages instead of exposing technical details
* Clear invalid values from form state automatically
* Cache provider options to reduce redundant calls
* Fix AJAX callback to use proper class reference
* Add accessibility attributes to error messages

I think there's a lot of overkill here. I tried testing a fresh 1.2.x with an invalid provider and it didn't cause any errors, but just reverted back to default. It does have a Try/Catch that it is hitting when trying to create an invalid instance. We can use that to alert the user their provider is not valid.

When using an invalid model on a valid provider, there was no error; however, it just used the default config. This one I believe we could gate by adding modal validating into the same try/catch as it's up to the provider to give this with getAvailableConfiguration($operation_type, $model);. OpenAi for example just gives you defaults if the model is invalid.

I think this entire problem goes away inside of `src/Service/AiProviderFormHelper.php` and with just providing the user a warning on exception.

in `generateAiProvidersForm()`

      try {
        $model = $form_state->getValue($prefix . 'ai_model', 'Undefined');
        $llmInstance = $this->aiProviderPluginManager->createInstance($provider);

        // .... other stuff

      catch (\Exception $e) {
        // Warn provider/model was set back to default or null if no default available.
      }

agree we can keep this simpler, in the existing try/catch around provider/model instantiation, on exception we can reset to default and set a clear user warning and still render the form so the user can choose another provider/model.
That should fix the “stuck when current provider is unavailable” case without the extra validation/caching.

Just show a user-facing warning when the provider/model is invalid or reverts to default.

I’ll simplify the MR to that approach, if all agree.
Will keep this open for suggestions for this week and implement if no one disagrees.

There have been no further updates or objections to the proposed simplified approach, so I’m picking this up and proceeding with the implementation.

I have rebased the MR branch and now phpstan is green. There is one warning for php unit next minor, but it is also not related to the change in this MR and it was seen before.

I also agree with the approach from MR 1278, as it is easier and straightforward.

Please make sure to manually verify the change is good as part of the review.

Sorry, I forgot to write that I have manually tested it.

Testing steps:

1. Install OpenAI provider and configure the key.
2. Install Anthropic provider and configure the key.
3. Create an Assistant, select OpenAI provider and the model.
4. Change the key for OpenAI provider here `/admin/config/system/keys` so it is not valid anymore.
5. Clear the caches.
6. Go to assistants page - observe the error message.
7. Now try to change to Anthropic. The provider can be changed without errors.
8. Change back to OpenAI - observe the error message again.
9. Try to save, observe the error message that the model needs to be selected.

thx, merged!