mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-07-09 17:19:02 +00:00
3bf0fa0af0
* feat(core): Add LSP server config hot-reload support - Implement reconcileServerConfigs to diff desired vs current LSP configs and apply minimal add/remove/restart operations with a serialized reconcile queue - Add configHash utility to detect config changes via stable hashing - Add lspConfigWatcher in CLI to watch .lsp.json and trigger reconciliation on file changes - Extend LspServerManager with per-server config hash tracking and detailed debug logging - Add design docs for LSP runtime reinitialization and hot-reload overview - Include comprehensive unit tests for all new modules * refactor(cli): Extract registerLspHotReload from main function Move the LSP config file watcher setup and reconciliation logic into a dedicated module-private function registerLspHotReload, reducing the size and nesting depth of the main startup flow. Added a JSDoc summarizing responsibilities, early-return conditions, and the AppEvent.LspStatusChanged side effect. * fix(lsp): release server resources during reload * fix(lsp): address hot reload review feedback * fix(lsp): harden hot reload reconciliation * docs(lsp): update hot reload design notes * fix(lsp): harden hot reload retry semantics * fix(lsp): harden hot reload lifecycle * fix(lsp): harden hot reload lifecycle * fix(lsp): isolate hot reload recovery paths * fix(lsp): align command probes and replay tracking * fix(lsp): prevent crash restarts during shutdown * fix(lsp): preserve reload state across failures * fix(lsp): cancel reloads during shutdown * fix(lsp): handle socket startup races * fix(lsp): harden command probe env and socket startup * fix(lsp): report skipped reload and restart states * fix(lsp): harden hot reload lifecycle cleanup * chore: add one comment for `Object.create(null)` --------- Co-authored-by: heyang.why <heyang.why@alibaba-inc.com> Co-authored-by: Shaojin Wen <shaojin.wensj@alibaba-inc.com> |
||
|---|---|---|
| .. | ||
| lsp-runtime-reinitialization.md | ||
| mcp-runtime-reinitialization.md | ||
| README.md | ||
| settings-change-detection.md | ||
Hot Reload Overall Plan
This directory tracks the design work for issue #3696: a comprehensive hot-reload system for skills, extensions, MCP servers, LSP servers, and runtime configuration.
Goal
Users should be able to update skills, extension state, MCP/LSP configuration, and supported settings without restarting the current Qwen Code session. The system should preserve conversation context while making runtime state changes predictable and visible.
Sub-task Breakdown
The hot-reload plan has 6 top-level sub-tasks. The current tracking issue splits sub-task 3 into 3a and 3b for implementation clarity, so the execution checklist contains 7 entries.
| Task | Scope | Status | Design document |
|---|---|---|---|
| 1 | Settings file change detection | Done in #4933 | settings-change-detection.md |
| 2 | Skill hot-reload improvements | Done via #2415 and #3923 | Not in this directory |
| 3a | MCP server runtime re-initialization | In progress via #5561 | mcp-runtime-reinitialization.md |
| 3b | LSP server runtime re-initialization | In progress | lsp-runtime-reinitialization.md |
| 4 | Unified refresh/cache orchestration | Not started | Pending |
| 5 | User-facing /reload slash command |
Not started | Pending |
| 6 | needsRefresh app-state/UI notification |
Not started | Pending |
Document Mapping
settings-change-detection.mdcorresponds to sub-task 1: Settings file change detection. It provides the watcher infrastructure: detect supportedsettings.jsonchanges, reload settings from disk, and notify listeners. It intentionally does not push updated values intoConfigsnapshots or restart runtime subsystems.mcp-runtime-reinitialization.mdcorresponds to sub-task 3a: MCP server runtime re-initialization. It consumes settings change events, updates the runtime MCP configuration, and incrementally reconciles live MCP connections. The original issue grouped MCP and LSP under top-level sub-task 3; this document covers the MCP half only.lsp-runtime-reinitialization.mdcorresponds to sub-task 3b: LSP server runtime re-initialization. It watches workspace.lsp.jsonchanges, reuses the existing native LSP client, and incrementally reconciles live LSP servers.
Implementation Order
- Keep sub-task 1 as the foundation: settings changes are detected and dispatched, but consumers decide what to refresh.
- Complete sub-task 3a so MCP server additions, removals, and configuration edits can take effect at runtime.
- Add sub-task 3b for LSP runtime re-initialization using the same principle: update runtime configuration, stop affected servers, and restart only what changed.
- Introduce sub-task 4 as the shared orchestration layer for cache and runtime refreshes across skills, commands, prompts, extensions, MCP, and LSP.
- Add sub-task 5 as the manual user entry point:
/reloadshould call the unified orchestration path and report what changed. - Add sub-task 6 for background-change UX: set
needsRefreshwhen a detected change cannot or should not be fully applied automatically, then prompt the user to run/reload.
Design Principle
Keep each layer narrow:
- file watching detects and reports settings changes;
- subsystem reinitialization updates only the affected runtime state;
- unified orchestration sequences existing refresh operations;
- UI commands and notifications expose the behavior without duplicating reload logic.