elton
509475e17a
Andreas: "kannst du neben dem goimapnotify einen mmnotify daneben setzen? das waere doch genau das werkzeug, was wir nun fuer alle brauchen. Auch gerne in go, auch gerne sehr robust, automatischer wiederaufbau und so." Dieselbe Bauform wie goimapnotify: ein kleiner Prozess, der lauscht und bei einem Ereignis einen Befehl ausfuehrt. Er schreibt nie selbst in einen Kanal -- er klopft nur an, der Agent liest und antwortet mit seinen eigenen Werkzeugen. Zwei Wege, und der Boden ist der tragende. Der Websocket beschleunigt, darunter laeuft ein Boden, der ohnehin nachsieht. Uebernommen aus hive (channels/team.py) und dort begruendet: ein Strom, der still ausfaellt, darf uns spaet machen, nie blind. Hier ist das nicht nur Vorsicht: Gegen Mattermost 11.7.10 gemessen kommt die Verbindung zustande, die Anmeldung wird mit status OK quittiert, und danach kommen hello und status_change -- aber KEIN posted, auch wenn ein anderes Konto in einen Kanal schreibt, in dem der Agent nachweislich Mitglied ist. Ursache offen, Verdacht sind Broadcasts an Verbindungen, die ueber ein Personal Access Token angemeldet sind. Mit dem Boden arbeitet der Dienst trotzdem, nur langsamer. Daraus folgt die zweite Entscheidung, ebenfalls von hive: mmnotify liest den Beitrag NICHT aus dem Ereignis. Zwei Leser waeren zwei Antworten. Robustheit, wo sie noetig ist: Wiederaufbau mit wachsendem Abstand bis 60 s; Herzschlag alle 30 s gegen halboffene Verbindungen; hoechstens ein Lauf gleichzeitig, sonst loesen fuenf Beitraege fuenf Agentenlaeufe aus, die sich ueberholen; eigene Beitraege und system-Ereignisse wecken nie.
mmnotify
Hört am Mattermost-Websocket und weckt einen Agenten, wenn er gemeint ist.
Gegenstück zu goimapnotify für
Mail: ein kleiner Prozess, der lauscht und bei einem Ereignis einen Befehl
ausführt. Der Agent liest und antwortet danach mit seinen eigenen Werkzeugen —
mmnotify schreibt nie in einen Kanal, es klopft nur an.
mmnotify -conf /etc/mmnotify.json
Konfiguration
{
"url": "https://team.42i.org",
"token": "<persönliches Zugriffstoken des Agenten>",
"on_mention": "/root/run-agent.sh team",
"on_direct": "",
"debounce_seconds": 5,
"floor_seconds": 60,
"ignore_users": []
}
Die Datei enthält ein Token und gehört mit 0600 dem Dienstbenutzer.
| Feld | Bedeutung |
|---|---|
on_mention |
Befehl bei Erwähnung (@name) im Kanal |
on_direct |
Befehl bei Direktnachricht; leer = on_mention |
debounce_seconds |
Mindestabstand zwischen zwei Läufen (Standard 5) |
floor_seconds |
Nachsehen auch ohne Ereignis (Standard 60, 0 schaltet ab) |
ignore_users |
Absender, die nie wecken |
Der Befehl bekommt die Ereignisdaten über die Umgebung: MM_TRIGGER
(event oder floor), MM_CHANNEL, MM_CHANNEL_NAME, MM_CHANNEL_TYPE,
MM_SENDER, MM_POST_ID, MM_ROOT_ID, MM_MESSAGE.
Zwei Wege, und der Boden ist der tragende
Der Websocket ist der Beschleuniger; darunter läuft ein Boden, der ohnehin
nachsieht. Die Aufteilung stammt aus hive (hive_runtime/channels/team.py) und
ist dort begründet: „A stream that dies quietly must make us LATE, never
blind."
Hier ist der Boden nicht nur Vorsicht. Gemessen am 2026-09-01 gegen
Mattermost 11.7.10: Die Verbindung kommt zustande, die Anmeldung wird mit
status: OK quittiert, danach kommen hello und status_change — aber
kein posted, auch wenn ein anderes Konto in einen Kanal schreibt, in dem
der Agent nachweislich Mitglied ist. Ursache offen; Verdacht sind Broadcasts an
Verbindungen, die über ein Personal Access Token angemeldet sind. Mit dem Boden
arbeitet der Dienst trotzdem, er ist dann nur langsamer.
Daraus folgt die zweite Entscheidung: mmnotify liest den Beitrag nicht aus dem Ereignis. Es klopft an; was zu tun ist, entscheidet der Agent, wenn er nachsieht. Zwei Leser wären zwei Antworten.
Robustheit
- Wiederaufbau mit wachsendem Abstand (1 s bis 60 s). Ein Server, der neu startet, wird nicht von einem Client bestürmt, der im Sekundentakt anklopft.
- Herzschlag alle 30 s, Lesefrist 90 s. Eine halboffene Verbindung liest sich sonst für immer wie Stille.
- Höchstens ein Lauf gleichzeitig; wer währenddessen schreibt, wird vom laufenden Durchgang mitgenommen. Ohne das lösen fünf Beiträge in einer Minute fünf Agentenläufe aus, die sich gegenseitig überholen.
- Eigene Beiträge und
system_*-Ereignisse wecken nie — sonst antwortet ein Agent auf sich selbst. SIGTERMbeendet sofort und sauber.
Bauen
go build -o mmnotify .
Ein statisches Binary ohne Laufzeitabhängigkeiten — gedacht zum Einbacken in
das Agenten-Image, neben goimapnotify.