Hermes AgentコミュニティがLSP修正を提案、TypeScript診断のタイムアウトでワークスペース全体のセマンティックチェックが無効化される可能性

Hermes Agentコミュニティは10月6日、エージェントがTypeScriptまたはJavaScriptファイルを書き込んだり修正したりした後、LSPのセマンティックチェックがタイムアウトまで結果を取得できず、その言語サーバーとワークスペースの組み合わせを障害状態として記録する可能性があると報告した。その後、同じワークスペース内のファイルはスキップされ、1回のタイムアウトが診断の欠落が続く状態に発展する。問題報告

報告者はWindows 11上でソースコードのmainブランチをテストし、number型に文字列を代入した。修正前のチェックは約62秒後に空の結果を返した一方、言語サーバーを直接起動すると約0.9秒で診断が届いた。この比較はHermesの通知処理経路に問題があることを示唆するが、単一環境でのコミュニティ測定であり、すべてのデプロイ環境で同様の遅延が起きるとは限らない。再現手順と測定結果

この問題は、古い診断を新しい結果と誤認しないための仕組みに関係している。TypeScriptサーバーはseed=Trueで登録され、クライアントは各ドキュメントで最初に受信したpublishDiagnosticsを基準値として扱い、待機条件を満たす通知としては認めない。しかし、報告されたケースではドキュメントに対してdidOpenだけが送信され、その後のdidChangeはなかったため、サーバーが結果を一度だけ送信した。この唯一の通知が除外された。修正の説明

同日に提出された修正案は、除外条件をドキュメントのバージョンが0より大きい場合に限定する。変更が送信されていない場合、最初の通知を有効な結果として扱える。変更が送信済みの場合は、古い基準値を遮断する保護を維持する。作者によると、新たに追加した2件のテストは成功し、LSPテストスイートでは106件が成功、3件がスキップされた。ただし、これらはブランチ上のテスト結果であり、正式リリースで修正済みであることを示すものではない。修正案とテスト

コーディングエージェントを使う際は、ファイルへの書き込みが成功したことと、セマンティックチェックが完了したことを別々に判断する必要がある。公式ドキュメントによると、LSPが失敗すると構文チェックにフォールバックするため、診断がないことを型が正しい証拠として扱うべきではない。影響を受けるチームは、まずログとhermes lsp statusを確認できる。再起動すれば障害状態は解除されるが、根本原因の解消には修正が必要だ。今後はマージとリリースへの取り込みを追跡するとともに、実際のプロジェクトでドキュメントを初めて開く経路と、連続して編集する経路の両方を検証する必要がある。公式LSPドキュメント