bug(desktop): enabling models one by one can stall Windows Settings → Models

[me2seeks]

What happened

On Windows Desktop, editing a provider under Settings → Models can become unresponsive when the user enables or disables models one by one. The reported symptom is an intermittent page hang and, in some cases, an apparent application crash while the model selection is being edited.

The current implementation saves every switch immediately through Runtime Host. This creates a potentially expensive and duplicated read/write path:

• use-connection-detail.ts calls connections:update for every individual model toggle and blocks later actions while the request is pending.
• runtime-host-connections-ipc-main.ts reads the complete Connection Catalog before the mutation and again after it, then emits connection_list_changed.
• The Settings surface, Providers panel, and App Shell each respond to that event with another catalog read; the detail hook also reloads after its update resolves.
• connection.catalog.update is a Host command. It is not automatically retried, and the direct request has no explicit operation timeout when the Host/storage lane remains responsive enough to pass liveness checks.

This issue tracks the provider-editor liveness/performance path. A Windows process crash still needs a native reproduction and crash/log evidence; the source investigation currently proves the conditions for a UI stall, not a confirmed Electron process crash.

How to reproduce

1. Use a Windows 11 x64 Desktop build from source or a current Windows preview.
2. Configure a provider with multiple chat-capable models, preferably a larger discovered catalog.
3. Open Settings → Models.
4. Open the provider detail editor.
5. Enable or disable several models individually in quick succession.
6. Observe whether each switch waits for a Runtime Host round trip, whether the page becomes disabled, and whether the app remains responsive while the catalog refreshes.
7. If the app becomes unresponsive or exits, capture the Desktop and Runtime Host logs from the same timestamp.

Environment

• Maka version or commit: 8dfc68d23 (source investigation; reproduce on the affected Windows build)
• OS and version: Windows 11 x64
• Surface: Desktop → Settings → Models → provider editor
• Runtime Host: local Host selected by Desktop
• Node.js: v26.3.0 when checked from the source workspace
• npm: 11.19.0 when checked from the source workspace

Logs, screenshots, or additional context

Relevant source paths:

• use-connection-detail.ts saves each enabled-model list independently and disables the detail actions while it is pending.
• runtime-host-connections-ipc-main.ts performs the Host update, emits the change event, and reads the projected connection again.
• catalog-reader.ts reconstructs the catalog through revision-consistent pages.
• reconnecting-connection.ts retries query operations but sends command operations through the current connection.
• connection.ts installs no per-request timer when a command caller does not provide timeoutMs.
• providers-panel.tsx, settings-surface.tsx, and use-shell-connections.ts all refresh on the connection-list event.

A Linux /tmp synthetic storage check with 300 discovered models did not show inherently slow local JSON writes, so model count alone is not established as the root cause. Windows-specific file commit/rename timing and Host process behavior still need to be measured.

Related but distinct:

• bug(desktop): Enable all fails when a model catalog exceeds 64 entries #3991 / bug(desktop): eanble all fails when a model catalog exceeds 64 entries. #3993 — Enable all fails above the enabled-model protocol limit; this report concerns repeated individual saves and liveness.
• bug(desktop): composer flashes "还没有可用的模型连接，无法发送" and blocks send during every connection snapshot refresh #4611 — Composer briefly loses its connection snapshot during refresh; this report concerns the provider editor and the refresh amplification behind it.
• fix(desktop): keep the model picker anchored during rapid pointer movement #5367 — Windows model picker anchoring race; this is a separate positioning issue.

Acceptance criteria

• Enabling several models individually does not cause the provider editor or Desktop to become unresponsive.
• Model selection writes are coalesced/batched, or equivalent bounded behavior prevents one Host round trip per click from amplifying into multiple full catalog reloads.
• Host mutation failure or timeout leaves the user’s draft selection visible and provides an actionable error.
• Connection-list refreshes are deduplicated by Host/catalog revision.
• Add a focused Desktop regression test with a delayed Host response and multiple model-toggle actions.
• Verify the final behavior on Windows 11 x64 with a provider having a larger model catalog.

[me2seeks]

take