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.
82 lines
3.1 KiB
Markdown
82 lines
3.1 KiB
Markdown
# mmnotify
|
|
|
|
Hört am Mattermost-Websocket und **weckt einen Agenten**, wenn er gemeint ist.
|
|
|
|
Gegenstück zu [`goimapnotify`](https://gitlab.com/shackra/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
|
|
|
|
```json
|
|
{
|
|
"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.
|
|
- `SIGTERM` beendet sofort und sauber.
|
|
|
|
## Bauen
|
|
|
|
```bash
|
|
go build -o mmnotify .
|
|
```
|
|
|
|
Ein statisches Binary ohne Laufzeitabhängigkeiten — gedacht zum Einbacken in
|
|
das Agenten-Image, neben `goimapnotify`.
|