セッションと配信

源码版本v2026.7.20

職務

二つの役:① セッション(Session)——「メッセージの出所」(プラットフォーム、chat、送信者)を安定した key にまとめ、対話をディスクに永続化し、agent が再起動を跨いでコンテキストを継続できるようにする。② 配信台帳(Delivery Ledger)——agent の最終返信に「送達義務」を1件記録し、クラッシュ時に未配信の返信を識別して再送し、ユーザーに最終的に届ける。どちらもゲートウェイ層にあり、agent とは疎結合。

主要ファイル

• class SessionSource:149-299 — メッセージ出所データクラス(platform/chat/sender、ハッシュ付き)
• class SessionContext:299-700 — セッションコンテキスト(key、出所、継続戦略)
• id ハッシュ:40-74 — _hash_id / _hash_sender_id / _hash_chat_id(プライバシー + 安定)
• パス安全校験:100-149 — _is_path_unsafe / _is_session_key_unsafe(session key がファイルシステムパスに流入)
• auto_continue 新鮮窓:26-40 — auto_continue_freshness_window
• 配信台帳ドキュメント:1-58 — 設計目標:best-effort、失敗で主フローを絶対ブロックしない
• compute_obligation_id:146-155 — 唯一の義務 id(セッション key + メッセージ ref + 内容)
• 状態機械:155-203 — record_obligation / mark_attempting / mark_delivered / mark_failed
• sweep_recoverable:203-276 — クラッシュ後に回復可能な義務を走査して再送
• SQLite 接続:77-102 — _db_path / _connect、ローカル sqlite に永続化

データフロー

1. アダプタがプラットフォームイベントを受け取り、MessageEvent:1759 経由で SessionSource を持ち出す。
2. SessionSource:149 が安定した chat/sender id をハッシュする(gateway/session.py:40)。
3. SessionContext:299 を構築し、session key を得る(パス安全校験:109 経由でディスクパスに使う)。
4. session key がどのファイルから履歴を読むかを決め、agent に渡してコンテキストを継続する。
5. agent が最終返信を出した後、ゲートウェイは record_obligation:155 で記帳 → 送信 → mark_delivered。
6. 送信中のクラッシュなら、次回起動時に sweep_recoverable(gateway/delivery_ledger.py:203) が attempting 状態かつ所有プロセスが死んだ義務を走査し、再送または失敗マークを付ける。

まとめ

セッション層は「このメッセージがどの継続対話に属するか」を担い、ハッシュ + パス校験で外部識別をディスクファイルに安全に写像する。配信台帳は「agent が送りたかった最終返信が本当にユーザーに届いたか」を担い、sqlite 状態機械でクラッシュ回復する。どちらも best-effort だが不可欠な信頼性層。