Hermes Agent 社群提出 LSP 修補，TypeScript 診斷逾時可能讓整個工作區停用語意檢查

Hermes Agent 社群於 10 月 6 日回報，代理寫入或修補 TypeScript、JavaScript 檔案後，LSP 語意檢查可能等到逾時仍拿不到結果，並將該語言伺服器與工作區的組合標記為故障。之後同工作區的檔案會被跳過，讓一次逾時擴大成持續缺少診斷的狀態。問題回報

回報者在 Windows 11、原始碼 main 分支測試，把字串指定給 number 型別。未修補時，檢查約 62 秒後回傳空結果；直接啟動語言伺服器則約 0.9 秒收到診斷。這組對照指向 Hermes 的通知處理路徑，但仍屬單一環境的社群測量，不能推定所有部署均有相同延遲。重現與測量

問題涉及防止舊診斷被誤當成新結果的機制。TypeScript 伺服器以 seed=True 註冊，客戶端把每份文件首次收到的 publishDiagnostics 留作基準，不讓它滿足等待條件。然而，案例中的文件只送出 didOpen、沒有後續 didChange，伺服器只推送一次結果；唯一可用的通知因此被排除。修補說明

同日提出的草稿將排除條件限縮到文件版本大於零：尚未送出變更時，首次通知可視為有效結果；變更已送出時，仍保留攔截舊基準的保護。作者回報兩項新增測試通過，LSP 測試組得到 106 項通過、3 項略過，但這些是分支測試結果，尚不代表正式發布已修復。修補與測試

這對編碼代理的意義是，檔案寫入成功與語意檢查完成必須分別判讀。官方文件說明，LSP 失敗會退回語法檢查，因此工程上不能把缺少診斷當成型別正確。受影響團隊可先查看日誌與 hermes lsp status；重啟能清除故障狀態，但根因仍需修補。接下來應追蹤合併與版本收錄，以及真實專案中首次開啟文件、連續修改文件兩條路徑的驗證。官方 LSP 文件