通知の送信元を手入力から実行レーンの自己申告へ移した
今回やったこと / この記事について
複数の自動レーンから同じ通知スクリプトを呼ぶ運用では、送信元を親プロセスのコマンド行から推測する方法が不安定になる。エージェントを起動するシェルが親になると、実際にどのレーンで発生した通知か分からず、存在しない呼び出し経路を調査することになる。そこで、レーン自身がリポジトリ相対パスをNOTIFY_SOURCEとして名乗り、その値を子プロセスへ渡す方式へ変更した。
推測から環境変数へ
agent_watchdog.shの_agent_notify_sourceは、明示されたAGENT_NOTIFY_SOURCE、既存のNOTIFY_SOURCE、実行中スクリプトのリポジトリ相対パスという順に名前を決める。run_with_watchdogはエージェント起動時に、まだ名前が設定されていなければこの値をNOTIFY_SOURCEへ入れる。これにより、エージェントの子孫が通知スクリプトを呼んでも、最初のレーンの名前が環境として残る。
この優先順位は、呼び出し元がすでに明示した名前を上書きしないために必要である。たとえば、別のラッパーがより正確なレーン名を設定している場合、その値を尊重する。一方、レーンの中で通知コマンドへ手入力した--sourceが、環境で確定したレーン名を上書きすると再び表記ゆれが生まれる。そのため通知側のresolve_sourceでは、実行レーンの自己申告を優先し、手入力値はsource_claimedとして台帳へ残す。
台帳の調査コストを下げる
この変更の目的は表示名を整えることだけではない。送信元が4種類の似た綴りに割れると、同じレーンの異常を別々のものとして集計してしまう。逆に、通知の出口で推測を続けると、通知を実際には呼んでいない検証スクリプトが送信元として記録される場合がある。発生源の契約を「通知を呼んだプロセス」ではなく「エージェントを起動したレーン」に置くことで、台帳をレーン単位で追跡できる。
| 記録項目 | 役割 |
|---|---|
source | 実行レーンとして確定した名前 |
source_claimed | 手入力されたが採用されなかった名前 |
NOTIFY_SOURCE | 子プロセスへ伝える実行時の契約 |
AGENT_NOTIFY_SOURCE | 上位ラッパーが明示する上書き可能な入力 |
手入力値を完全に捨てない点も重要である。採用しない値を台帳に残せば、どのプロンプトやスクリプトが古い名前を出しているかを後から確認できる。表記ゆれを隠して綺麗に見せるのではなく、正規化した値と元の申告を分けて保存する。
配線をgrepだけで終わらせない
test_notify_source_wiring.pyは、名前を解決できることだけでなく、実際に子プロセスへ届くことを確認する。watchdogを通した子プロセスではレーン名が出力され、watchdogを通さない対照群ではunsetのままになる。さらに、エージェントを直接起動するシェルと通知を呼ぶワークフローを走査し、NOTIFY_SOURCEまたはrun_with_watchdogが無い配線を検出する。
最後に、子プロセスが手入力で--sourceを指定するケースも実プロセスで確認する。正規化後のsourceがレーン名になり、手入力値だけがsource_claimedに残ることまで検査する。設定ファイルだけを点検しても、環境変数の継承や優先順位の誤りは見えないため、実際の親子関係を通すテストにしている。
試した環境・参照
- Bashレーン、エージェント子プロセス、Python通知スクリプト
- 通知スクリプト、エージェント監視ラッパー、配線テスト、設定ファイル
やってみてわかったのは、通知の送信元は本文の語彙ではなく、実行境界で決めるべきだということだ。レーンが自分の名前を環境へ渡し、出口側がそれを正規化して記録する構成にすると、調査時に親プロセスを推理する必要が減る。対照群を含む配線テストまで置くことで、新しいレーンを追加した時の漏れも検出できる。
更新履歴
- 2026-09-18: 初稿。通知送信元の自己申告と配線テストを整理。
訂正履歴
なし。