Andreas: "koennen wir da nicht noch einbauen das der nur feuert wenn
tatsaechlich was anliegt? das wuerde ich nicht dem client ueberlassen
sondern schon im notifier loesen. der mail notifier muss doch auch sowas
machen." Richtig -- und der Vergleich trifft den Kern: goimapnotify hat
das Problem nicht, weil IMAP IDLE ein echtes Ereignis liefert. Bei
Mattermost fehlt der Push fuer Kanaele, und mein Boden hat das mit
blindem Feuern ausgeglichen.
Jetzt sieht der Boden selbst nach: je Kanal ein posts?since=<marke>, das
bei Stille leer zurueckkommt. Eigene Beitraege und system-Ereignisse
zaehlen nicht, sonst loeste die eigene Antwort den naechsten Durchgang
aus. Ein Dutzend Kanaele bei 60 s Takt sind zwoelf Anfragen pro Minute --
gegen einen Modelllauf ist das nichts.
Der Weg dahin war laenger als noetig, weil drei Mattermost-Felder auf
dieser Instanz luegen: last_post_at blieb nach einem neuen Beitrag
unveraendert, msg_count zaehlte weiter obwohl der Kanal als gesehen galt,
und last_viewed_at war neuer als die ungelesenen Beitraege. posts?since=
ist das einzige, das nachweislich stimmt.
Gemessen: zwei Durchgaenge Stille ohne einen einzigen Aufruf des
Befehls, dann ein fremder Beitrag -> gefeuert. Genau das Verhalten von
goimapnotify.
Andreas: "dann durchsuch noch mal die foren, das kann doch nicht sein
das das niemand da draussen hat das problem." Hatte jemand, und der
entscheidende Satz stand in einem Bugreport eines anderen Projekts:
"DMs work fine."
Nachgemessen, und es stimmt:
Direktnachricht -> posted kommt SOFORT
eigener Kanalbeitrag -> posted kommt
Kanalbeitrag eines anderen -> kommt nie
Damit ist die Lage eine voellig andere als gedacht. Mit einem Agenten zu
reden -- der Anwendungsfall, um den es Andreas ging -- laeuft in Echtzeit
ueber eine DM. Der Boden deckt nur noch Erwaehnungen in Kanaelen ab, und
das ist der Fall, bei dem 15 Sekunden niemanden stoeren.
Dabei ausserdem einen eigenen Fehler korrigiert: Ich hatte den Test
"direkt am Container, ohne Caddy" als erledigt dargestellt, obwohl das
sed dafuer fehlgeschlagen war und gegen den Proxy gemessen wurde.
Nachgeholt: ws://192.168.1.142:8065 direkt verhaelt sich genauso. Der
Proxy ist jetzt wirklich ausgeschlossen.
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