Sitzung und Zustellung

源码版本v2026.7.20

Verantwortung

Zwei Dinge: (1) Sitzung (Session) – «woher die Nachricht kommt» (Plattform, Chat, Sender) wird auf einen stabilen Key abgebildet und der Dialog auf der Platte persistiert, sodass der Agent über Neustarts hinweg Kontext fortsetzt; (2) Delivery Ledger – für die finale Antwort des Agenten wird eine «Zustellverbindlichkeit» verbucht; nach einem Crash kann das Gateway unzustellbare Antworten erkennen und nachsenden, sodass der Nutzer sie letztlich erhält. Beide liegen im Gateway und sind vom Agenten entkoppelt.

Schlüsseldateien

• class SessionSource:149-299 — Datenklasse der Nachrichtenquelle (platform/chat/sender, mit Hash)
• class SessionContext:299-700 — Sitzungskontext (Key, Quelle, Fortsetzungsstrategie)
• ID-Hash:40-74 — _hash_id / _hash_sender_id / _hash_chat_id (Privatsphäre + Stabilität)
• Pfad-Sicherheitsprüfung:100-149 — _is_path_unsafe / _is_session_key_unsafe (Session-Key fließt in Dateisystem-Pfade)
• auto_continue Frische-Fenster:26-40 — auto_continue_freshness_window
• Delivery-Ledger-Doku:1-58 — Designziel: best-effort, Fehler blockieren nie den Hauptfluss
• compute_obligation_id:146-155 — eindeutige Verbindlichkeits-ID (Session-Key + Nachrichten-Ref + Inhalt)
• Zustandsautomat:155-203 — record_obligation / mark_attempting / mark_delivered / mark_failed
• sweep_recoverable:203-276 — scannt nach Crash recoverable Verbindlichkeiten und sendet nach
• SQLite-Verbindung:77-102 — _db_path / _connect, persistiert in lokalem SQLite

Datenfluss

1. Der Adapter empfängt ein Plattform-Event und extrahiert über MessageEvent:1759 die SessionSource.
2. SessionSource:149 hasht eine stabile Chat-/Sender-ID (gateway/session.py:40).
3. Konstruktion des SessionContext:299, ergibt den Session-Key (nach Pfad-Sicherheitsprüfung:109 als Platten-Pfad genutzt).
4. Der Session-Key bestimmt, aus welcher Datei die Historie geladen und dem Agenten zum Kontextfortsetzen gefüttert wird.
5. Sobald der Agent die finale Antwort erzeugt hat, verbucht das Gateway in record_obligation:155 → senden → mark_delivered.
6. Wenn beim Senden ein Crash passiert, scannt beim nächsten Start sweep_recoverable (gateway/delivery_ledger.py:203) Verbindlichkeiten im Status attempting mit totem Besitzer-Prozess und sendet nach oder markiert als failed.

Zusammenfassung

Die Sitzungsschicht ist zuständig für «zu welchem andauernden Dialog gehört diese Nachricht» und bildet die externe Identität per Hash + Pfad-Prüfung sicher auf Plattendateien ab. Das Delivery-Ledger ist zuständig für «ob die finale Antwort des Agenten wirklich beim Nutzer ankam» und macht über einen SQLite-Zustandsautomaten Crash-Recovery. Beides ist best-effort, aber eine unverzichtbare Zuverlässigkeitsschicht.