fix(gui): ignore stale provider model fetch results after provider switch

[shaun0927]

Fixes #12150

Summary

• ignore late dynamic-model fetch results after the selected provider changes
• keep the fix scoped to AddModelForm rather than introducing global request cancellation
• add a focused regression test that reproduces the in-flight fetch + provider switch race

Why this change

PR #12046 introduced dynamic provider model fetching. That flow works, but the current callback in gui/src/forms/AddModelForm.tsx closes over selectedProvider, so a request started for provider A can still update fetchedModelsList after the user has switched to provider B.

That leaves the Add Model UI in an inconsistent state where stale models from the previous provider appear under the newly selected provider.

This PR fixes that by tracking the currently selected provider at resolution time and ignoring outdated async results.

Test plan

• cd gui && npm test -- --run src/forms/AddModelForm.dynamicFetchRace.test.tsx
• Reproduced the stale-result leak locally before the fix using the focused regression test
• Verified the same test passes after the fix
• Full GUI test suite
• Manual validation in VS Code / JetBrains

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[cubic-dev-ai]

No issues found across 2 files

[chatgpt-codex-connector]

💡 Codex Review

continue/core/llm/fetchModels.ts

Lines 227 to 231 in 08e0a7b

	const llm = llmFromProviderAndOptions(provider, {
	apiKey,
	apiBase: apiBase || defaultApiBase,
	model: "",
	});

Pass provider-specific fields when building model fetch client

fetchProviderModelsViaListModels creates the provider client with only apiKey, apiBase, and model: "", so provider-specific required options are never forwarded. This breaks dynamic model fetching for providers like Azure that need additional fields (for example deployment/apiVersion/apiType): Azure falls back to an empty deployment and builds a /openai/deployments//models endpoint, so the fetch path fails even when the form is filled out correctly.

---

continue/gui/src/forms/AddModelForm.tsx

Lines 58 to 60 in 08e0a7b

	useEffect(() => {
	selectedProviderRef.current = selectedProvider.provider;
	}, [selectedProvider]);

Update provider race guard synchronously on provider change

The stale-response guard relies on selectedProviderRef, but this ref is updated in a passive useEffect. That leaves a timing window right after switching providers where an older in-flight request can resolve before the effect runs, still see the previous provider in the ref, and incorrectly write stale models into state. This means the provider-switch race can still reproduce under fast interactions.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[shaun0927]

I have read the CLA Document and I hereby sign the CLA

[shaun0927]

recheck

[shaun0927]

Addressed the provider-switch timing window in fbd092c by updating the provider ref synchronously when the selection changes, and formatted the regression test so the Prettier check should pass on the rerun.

I did not fold the fetchProviderModelsViaListModels feedback into this PR because it affects a broader core model-fetch path and is not required to fix the validated Add Model race tracked in #12150. I want to keep this PR scoped to the user-visible stale-result leak and its regression coverage.

[chatgpt-codex-connector]

💡 Codex Review

continue/gui/src/forms/AddModelForm.tsx

Lines 132 to 134 in fbd092c

	if (!selectedProvider.tags?.includes(ModelProviderTags.RequiresApiKey)) {
	formMethods.setValue("apiKey", "");
	}

Clear API key when switching keyed providers

This effect only clears apiKey when the newly selected provider does not require a key, but handleFetchModels later sends the current apiKey to whatever provider is selected. If a user switches from one keyed provider to another (for example OpenAI to Anthropic) and clicks fetch before replacing the field, the previous provider's secret is transmitted to the wrong API. This is a cross-provider credential leak path introduced by dynamic model fetching; reset or scope API keys per provider on every provider switch.

---

continue/core/llm/fetchModels.ts

Line 233 in fbd092c

return modelIds.map((id) => ({ name: id }));

Filter fetched model IDs to chat-capable entries

This returns every ID from llm.listModels() as a selectable chat model without any modality/capability filtering. For OpenAI-compatible providers, /models commonly includes non-chat IDs (embeddings, audio, moderation, etc.), so users can add an invalid chat model and later hit runtime failures during completion. Filter these results to chat-capable models (or provider-specific allowlists) before exposing them in Add Chat Model.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[shaun0927]

Addressed the remaining in-scope Codex P1 in 1078373: switching between two providers that both require API keys now clears the shared apiKey field before another fetch can run, and the regression test now covers that keyed-to-keyed switch.

I still left the broader fetchProviderModelsViaListModels / chat-capability filtering feedback out of this PR on purpose, since those touch wider model-fetch semantics beyond the validated stale-result race and follow-up credential-leak fix tracked here.

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="gui/src/forms/AddModelForm.tsx">

<violation number="1" location="gui/src/forms/AddModelForm.tsx:132">
P2: Clearing the API key on every provider change discards valid credentials when switching between API-key providers.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[chatgpt-codex-connector]

💡 Codex Review

continue/gui/src/forms/AddModelForm.tsx

Lines 58 to 60 in 1078373

	useEffect(() => {
	setFetchedModelsList([]);
	}, [selectedProvider]);

Clear fetch lock when provider selection changes

When a model fetch is started for provider A and the user switches to provider B before it resolves, this effect only clears fetchedModelsList and leaves isFetchingModels true. Because the fetch button is gated by disabled={isFetchingModels}, provider B cannot fetch models until provider A's request completes (and if that request hangs, B stays blocked indefinitely), even though stale results are ignored via selectedProviderRef.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[shaun0927]

Follow-up pushed in 9deaa89 for the latest review finding.

• cubic found that provider switches were still inheriting the previous fetch lock even after stale results were ignored
• provider changes now invalidate stale fetch generations and release the lock for the newly selected provider immediately
• added regression coverage for the pending-fetch + provider-switch + immediate-refetch path

Validation:

• cd gui && npm test -- --run src/forms/AddModelForm.dynamicFetchRace.test.tsx
• cd gui && npx prettier --check src/forms/AddModelForm.tsx src/forms/AddModelForm.dynamicFetchRace.test.tsx --ignore-path ../.gitignore --ignore-path ../.prettierignore

@cubic-dev-ai please re-run review on the latest head.

[cubic-dev-ai]

Follow-up pushed in 9deaa89 for the latest review finding.

• cubic found that provider switches were still inheriting the previous fetch lock even after stale results were ignored
• provider changes now invalidate stale fetch generations and release the lock for the newly selected provider immediately
• added regression coverage for the pending-fetch + provider-switch + immediate-refetch path
  ...

@shaun0927 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="gui/src/forms/AddModelForm.tsx">

<violation number="1" location="gui/src/forms/AddModelForm.tsx:81">
P2: Stale fetch results can be applied again after switching away and back to the same provider because the response is guarded only by provider identity, not the request generation.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[cubic-dev-ai]

P2: Stale fetch results can be applied again after switching away and back to the same provider because the response is guarded only by provider identity, not the request generation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At gui/src/forms/AddModelForm.tsx, line 81:

<comment>Stale fetch results can be applied again after switching away and back to the same provider because the response is guarded only by provider identity, not the request generation.</comment>

<file context>
@@ -72,13 +78,15 @@ export function AddModelForm({
-      setFetchedModelsList((prev) =>
-        selectedProvider.provider === providerAtFetchTime ? models : prev,
-      );
+      if (selectedProviderRef.current === providerAtFetchTime) {
+        setFetchedModelsList(models);
+      }
</file context>

Suggested change

	if (selectedProviderRef.current === providerAtFetchTime) {
	if (
	selectedProviderRef.current === providerAtFetchTime &&
	fetchGenerationRef.current === fetchGeneration
	) {

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9deaa89bc9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Guard fetched model updates by request generation

This update only checks selectedProviderRef before applying results, so two concurrent fetches for the same provider can still race: if a user clicks refresh twice (or changes API key/API base and refetches), the older request may resolve last and overwrite the newer model list. That reintroduces stale models in the picker even though fetchGenerationRef is already tracked; the generation check should also gate setFetchedModelsList.

Useful? React with 👍 / 👎.