Skip to content

fix: cloud chat /chat startup failures (422 + Azure api_version)#1605

Merged
4pmtong merged 1 commit into
testfrom
fix/cloud-chat-startup-422-and-azure
May 1, 2026
Merged

fix: cloud chat /chat startup failures (422 + Azure api_version)#1605
4pmtong merged 1 commit into
testfrom
fix/cloud-chat-startup-422-and-azure

Conversation

@4pmtong
Copy link
Copy Markdown
Collaborator

@4pmtong 4pmtong commented May 1, 2026

Related Issue

Closes #

Description

Fixes two cascading failures that broke /chat startup in cloud mode, plus a dev-server proxy resilience tweak.

1. Frontend — chat input model dropdown out of sync (422 on /chat)

ChatInputModelDropdown.tsx's cloudModelOptions listed ids that don't exist in the canonical CloudModelType / CLOUD_MODEL_PLATFORM_MAP (gpt-5, gpt-5.1, gpt-5.2, gpt-4.1, gpt-4.1-mini, minimax_m2_5) and was missing the current ones (gpt-5.5, claude-opus-4-7, deepseek-v4-pro, minimax_m2_7). Selecting a stale id made getCloudModelPlatform() return undefined, JSON.stringify dropped model_platform from the body, and the backend Pydantic model rejected /chat with 422 Unprocessable Entity.

  • Synced the dropdown with the canonical list (the same one Models.tsx uses).
  • Bumped auth-storage persist version 6 → 7 with a migration that resets stale persisted cloud_model_type values to a supported default, so users with e.g. gpt-5.2 already in localStorage don't keep hitting 422 after upgrading.

2. Backend — Azure cloud mode crashed with no api_version

After picking a valid Azure-backed model (gpt-5.4 / 5.5 / -mini), the backend then crashed inside camel's AzureOpenAIModel:

ValueError: Must provide either the `api_version` argument or `AZURE_API_VERSION` environment variable.

The cloud frontend ships extra_params: {}. Bedrock already had patch_bedrock_cloud_config to default region_name and rewrite the URL — Azure had no equivalent.

  • Added patch_azure_cloud_config() defaulting api_version to GA 2024-10-21.
  • Wired it into agent_model.py and mcp.py next to the Bedrock patch.

3. Dev — /api proxy TLS handshake churn

Behind a local fakeip proxy (Clash / Surge / etc.), npm run dev:web was intermittently logging Client network socket disconnected before secure TLS connection was established because Vite's default proxy opens a new TLS connection per request. Enabled keep-alive HTTP/HTTPS agents on the /api proxy to amortize handshakes.

Testing Evidence (REQUIRED)

  • I have included human-verified testing evidence in this PR.
  • This PR includes frontend/UI changes, and I attached screenshot(s) or screen recording(s).
  • No frontend/UI changes in this PR.

What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Contribution Guidelines Acknowledgement

@4pmtong 4pmtong merged commit caf4aff into test May 1, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant