Hermes Agentコミュニティ、リセット後のタスク通知漏れを調査　バックグラウンドプロセスの中断が既読扱いになる可能性

Hermes Agentコミュニティは10月12日、バックグラウンドタスクのライフサイクルに関する報告を行った。Telegramで実行中の長時間タスクが、関連するエージェントの終了後に停止したにもかかわらず、ユーザーには対応可能な中断通知が届かなかったという。報告者は後にログを確認し、この事象がセッションリセット時のクリーンアップ経路を通っていたことを突き止めた。ログからは、入口が/new、/reset、または同じハンドラーへの別の呼び出しのいずれだったかを区別できないため、プロセスの終了を誤った強制終了と断定することはできない。事象とその後の調査

別の参加者は、当時のメインブランチにある実際のプロセス登録処理とエージェントのクリーンアップ関数を使って、一部の実行テストを行った。その結果、kill_processがconsume_output=Trueを指定すると、終了させられたプロセスの完了結果が消費済みとして扱われ、未読完了リストと通知ゲートでスキップされると指摘した。比較では、自発的に終了したプロセスには通知が届き、値をFalseに変えると、終了させられたプロセスの結果も再び通知対象になった。ただし、このテストではTelegramとセッションデータベース全体の処理を実行していない。リセット後のメッセージの帰属先も、別途検証が必要な課題として残っている。コミュニティによるテスト

これは、バックグラウンド通知に関する公式ドキュメントの仕様に直接関わる。notify_on_complete=trueの場合、プロセス完了後に新しいエージェントターンが開始され、エージェントが結果を報告する。通常の通知モードでは、完了または失敗の状態を送信できる。エンジニアリングの観点では、タスクの起動、終了イベントの受信、結果の会話への返送という3つの段階を、それぞれ個別に検証する必要がある。メッセージングゲートウェイのドキュメント

公式の実行環境ドキュメントによると、実行中のプロセスのチェックポイントと完了時の出力は別々に保存される。また、結果の読み取りは、元のセッションまたはその圧縮後の継続セッションが持つ権限によって制限される。つまり、別の会話に引き継ぐには、プロセスIDを保持するだけでなく、結果の帰属先と通知のルーティングも扱わなければならない。ツール実行環境のドキュメント

長時間の調査やバッチ処理を実行するチームにとって、この事例は、タスクが自ら書き込むrunning状態だけではプロセスがまだ動いている証拠にならないことを示している。今後は、中断通知、実行を継続しているタスクの結果配信、二重実行を防ぐ復旧フローを含む、リセット時のエンドツーエンドテストがメンテナーによって追加されるかが焦点となる。確認時点でissueはオープンのままメンテナーの判断を待っており、関連する修正PRはない。現時点の証拠はさらなる調査を支持するものの、すべてのデプロイ環境に影響しているとは結論できない。issueの状態