Andreas: "waehrend mmnotify per ws angemeldet ist, kann es dann den
status des agenten auf online setzen?" Ja -- und hive hatte das Muster
schon fertig (channels/team.py): abwesend beim Verbinden, gruen waehrend
der Arbeit, wieder abwesend nach Ruhe, offline beim Beenden. Ein Agent
ohne Status sieht aus, als sei niemand da; einer, der rund um die Uhr
gruen leuchtet, sagt genauso wenig.
Beim Testen fiel ein eigener Fehler auf: Der Boden setzte den Agenten auf
gruen. Routinemaessiges Nachsehen ist aber keine Anwesenheit -- bei Boden
alle 20 s und Frist 25 s blieb er dauerhaft gruen. Jetzt macht nur ein
echtes Ereignis gruen.
Und zur Verzoegerung, die Andreas zu Recht nicht hinnehmen wollte: Statt
weiter zu raten, gemessen. Der eigene Beitrag loest sehr wohl ein posted
aus, ein fremder nie -- die Verbindung hat also die Kanal-Abos, es fehlen
nur fremde Ereignisse. Ausgeschlossen: authentication_challenge, Token im
Authorization-Header, ein echter Bot-Account statt Nutzer-Token, und das
Sitzungs-Cookie wie im Browser. Alle vier gleich. Das Mattermost-Forum
beschreibt dasselbe, dort auch mit System-Admin-Token, ohne Loesung.
Konsequenz: floor_seconds ist der Weg, nicht der Notnagel, und steht
deshalb auf 15 s statt 60. Ein Durchgang kostet einen API-Aufruf -- billig
genug, um es oft zu tun.
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.
elton