Hermesコミュニティ、デスクトップ版とDocker版のバージョン不一致を報告。更新後にリモート会話を作成できない可能性

Hermes Agentコミュニティは10月2日、Windowsデスクトップ版からNAS上のDockerバックエンドに接続した際、デスクトップ版を更新すると新しい会話を作成できなくなったと報告した。報告された環境はDesktop 0.21.5+4856と、バージョン0.21.5のコンテナイメージ。報告者によると、既存の会話とTelegramは引き続き使え、障害はリモートで新しいセッションを作成する処理に限られていた。問題の報告

報告によると、新しいデスクトップ版はsession.createリクエストにcwd_explicitを追加するが、旧バックエンドのパラメーター構造体は追加フィールドを許可しないため、リクエストを拒否する。これにより、インターフェースの更新がRPC互換性の問題に発展する。追加フィールドが補助情報を運ぶだけでも、厳密な検証を行う受信側が呼び出し全体を無効と判定する可能性がある。現時点では単一のデプロイ環境での事例であり、影響するバージョンやプラットフォームの全範囲は確認されていない。エラーと再現手順

公式ドキュメントには、更新経路の違いが説明されている。通常のhermes updateはmainの最新コードを取得する。一方、Dockerインストールではイメージソースのタグから管理方法を判別し、コンテナ内のアプリケーションを直接書き換えることを拒否するため、イメージを取得して置き換える必要がある。その結果、両者のコミットが異なる状態になることがあり、操作画面でどちらも更新完了と表示されても、プロトコルの整合性が保たれているとは限らない。更新ドキュメント

複数接続に関するデスクトップ版のドキュメントでは、一括更新時に各バックエンドを個別に処理すると説明している。DockerやNixなど、外部で管理されるインストール環境は更新を拒否でき、デスクトップアプリはその後に更新される。この報告を踏まえると、デプロイ手順では「バックエンドは更新を拒否したが、クライアントはアップグレードされた」という互換性の境界に対処する必要があると推測できる。ただし、ドキュメント自体は、こうした組み合わせがすべて障害を起こすとは確認していない。複数インスタンスの更新方式

エンジニアリングチームは、デスクトップ版のコミット、コンテナのバージョン、イメージソースの情報を記録し、アップグレードの受け入れ確認でリモートの新規会話作成を実際にテストするとよい。報告者は、プロトコルのバージョンネゴシエーション、バックエンドの機能に応じたフィールドの省略、対応するイメージバージョンに合わせたデスクトップ更新チャネルを提案している。確認時点でこのIssueはオープンのままで、ページには関連する修正が記載されていない。これらの提案を、公開済みの解決策と見なすことはできない。Issueの状況と提案