iris/Iris
1
0
Fork 0
Code Issues 23 Pull requests Projects Releases Packages Wiki Activity Actions

Hermes-Lauf: Maximale Laufzeit des Watchdogs einstellbar, Abbruchgrund anzeigen #333

New issue
Open
opened 2026-11-06 18:50:33 +00:00 by alf · 1 comment
alf commented 2026-11-06 18:50:33 +00:00
Owner
Copy link

Problem

Der Circuit Breaker HermesRunWatchdog stoppt jeden Hermes-Lauf nach 45 Minuten Gesamtdauer (maxTotalRunDuration, fest einprogrammiert), auch wenn der Lauf Fortschritt macht. Lange Läufe (Recherche an einem Arcade-ROM mit dem Plugin iris-rea-recherche, lokales Modell mit 40 bis 80 s je API-Aufruf) brechen deshalb alle 45 Minuten mit „⏹️ Hermes-Job abgebrochen." ab, ohne dass der Nutzer erfährt, warum.

Belegt im Log des MacBooks (~/.hermes/logs/agent.log, 2026-11-06): Läufe 16:06:09 → 16:51:45, 16:52:26 → 17:37:48, 17:38:17 → 18:23:50, jeweils POST /v1/runs/<id>/stop von Iris nach 45:22 bis 45:36 Minuten, während der Lauf normal Tools aufrief und Dateien schrieb.

Warum

Der Watchdog soll hängende Läufe und Endlosschleifen begrenzen (Vorfall 2026-08-05). Eine feste Grenze trifft aber auch legitime lange Arbeit. Nach der Regel „nie Settings hardcoden" gehört der Wert in eine Einstellung.

Umfang (Weg 1)

  • Einstellung „Maximale Laufzeit" für Hermes-Läufe, Standard weiterhin 45 Minuten; Auswahl 30 Min bis 8 Std (Companion-Panel, Sonstiges). Der Watchdog liest den Wert bei jeder Prüfung, eine Änderung gilt auch für laufende Läufe.
  • Beim automatischen Stopp nennt die Chat-Meldung den Grund und den Hinweis auf die Einstellung statt nur „abgebrochen".
  • Der Silence-Timeout (10 Minuten ohne Ereignis) bleibt unverändert.

Nicht im Umfang

Fortschrittsbewusster Timer (Weg 2); Linux-Server (hat keinen solchen Watchdog).

## Problem Der Circuit Breaker `HermesRunWatchdog` stoppt jeden Hermes-Lauf nach 45 Minuten Gesamtdauer (`maxTotalRunDuration`, fest einprogrammiert), auch wenn der Lauf Fortschritt macht. Lange Läufe (Recherche an einem Arcade-ROM mit dem Plugin iris-rea-recherche, lokales Modell mit 40 bis 80 s je API-Aufruf) brechen deshalb alle 45 Minuten mit „⏹️ Hermes-Job abgebrochen." ab, ohne dass der Nutzer erfährt, warum. Belegt im Log des MacBooks (`~/.hermes/logs/agent.log`, 2026-11-06): Läufe 16:06:09 → 16:51:45, 16:52:26 → 17:37:48, 17:38:17 → 18:23:50, jeweils `POST /v1/runs/<id>/stop` von Iris nach 45:22 bis 45:36 Minuten, während der Lauf normal Tools aufrief und Dateien schrieb. ## Warum Der Watchdog soll hängende Läufe und Endlosschleifen begrenzen (Vorfall 2026-08-05). Eine feste Grenze trifft aber auch legitime lange Arbeit. Nach der Regel „nie Settings hardcoden" gehört der Wert in eine Einstellung. ## Umfang (Weg 1) - Einstellung „Maximale Laufzeit" für Hermes-Läufe, Standard weiterhin 45 Minuten; Auswahl 30 Min bis 8 Std (Companion-Panel, Sonstiges). Der Watchdog liest den Wert bei jeder Prüfung, eine Änderung gilt auch für laufende Läufe. - Beim automatischen Stopp nennt die Chat-Meldung den Grund und den Hinweis auf die Einstellung statt nur „abgebrochen". - Der Silence-Timeout (10 Minuten ohne Ereignis) bleibt unverändert. ## Nicht im Umfang Fortschrittsbewusster Timer (Weg 2); Linux-Server (hat keinen solchen Watchdog).
alf commented 2026-11-06 18:51:41 +00:00
Author
Owner
Copy link

PR #334 gemergt: feat(hermes): Maximale Laufzeit des Watchdogs einstellbar, Abbruchmeldung nennt den Grund (#333)
http://docker:3000/iris/Iris/pulls/334

Commits:

  • feat(hermes): Maximale Laufzeit des Watchdogs einstellbar, Abbruchmeldung nennt den Grund (#333)

Stand: umgesetzt (Weg 1), gebaut nur als Quelltext, nicht in der App.

Befund: HermesRunWatchdog.maxTotalRunDuration war fest 45 Minuten. Im Log des MacBooks (2026-11-06) stoppte Iris drei Läufe (16:06→16:51, 16:52→17:37, 17:38→18:23) nach 45:22 bis 45:36 Minuten per POST /v1/runs/<id>/stop, obwohl sie Tools aufriefen und Dateien schrieben. Die Meldung „Hermes-Job abgebrochen." nannte keinen Grund.

Geändert:

  • Neu Iris/HermesRunLimits.swift (nur Foundation): Schlüssel hermesMaxRunMinutes, Standard 45, Auswahl 30/45/60/120/240/480 Minuten, gespeicherte Werte werden auf 10 Minuten bis 24 Stunden begrenzt (ein Wert von Hand kann den Schutz nicht abschalten).
  • HermesRunWatchdog: liest die Grenze bei jeder Prüfung (gilt auch für laufende Läufe), merkt sich den Stoppgrund vor dem Stopp (takeTripReason).
  • AgentJob: die Meldung nach einem Watchdog-Stopp nennt den Grund und den Hinweis auf die Einstellung (vorher nur „abgebrochen").
  • CompanionPanelView: Picker „Maximale Laufzeit“ unter Sonstiges; Localizable.xcstrings mit den deutschen Texten.
  • Silence-Timeout (10 Minuten ohne Ereignis) unverändert. Linux-Server hat keinen solchen Watchdog.

Geprüft: Die Rechnung von HermesRunLimits mit swiftc und einem kleinen Testprogramm außerhalb der App (12 Prüfungen: Standard bei fehlendem Wert, Unter- und Obergrenze, Sekunden, Auswahlliste mit Sonderwert, Beschriftung, Meldung); mit ausgebauter Klammerung schlagen die Grenzfälle fehl. swiftc -typecheck über HermesRunLimits, HermesRunWatchdog, HermesGatewayClient und IrisConfig: keine Fehler in den geänderten Dateien (Fehler nur durch fehlende Nachbardateien). Localizable.xcstrings bleibt gültiges JSON.

Nicht geprüft: Bauen der App (xcodebuild im Terminal ist ausgeschlossen, TCC); die Änderungen in AgentJob.swift und CompanionPanelView.swift wurden nicht typgeprüft und die Oberfläche nicht angesehen; ein echter Lauf über die Grenze (Stopp mit Grund) auf dem MacBook; dass der Picker einen Wert wirklich speichert und der Watchdog ihn beim nächsten Poll nutzt. Der Lauf auf dem MacBook läuft mit dem alten Build, bis dort ein neuer Build installiert ist.

Offen: Weg 2 (fortschrittsbewusster Timer: nur Läufe stoppen, die keine neuen Ergebnisse liefern).

PR #334 gemergt: feat(hermes): Maximale Laufzeit des Watchdogs einstellbar, Abbruchmeldung nennt den Grund (#333) http://docker:3000/iris/Iris/pulls/334 Commits: - feat(hermes): Maximale Laufzeit des Watchdogs einstellbar, Abbruchmeldung nennt den Grund (#333) --- **Stand: umgesetzt (Weg 1), gebaut nur als Quelltext, nicht in der App.** **Befund:** `HermesRunWatchdog.maxTotalRunDuration` war fest 45 Minuten. Im Log des MacBooks (2026-11-06) stoppte Iris drei Läufe (16:06→16:51, 16:52→17:37, 17:38→18:23) nach 45:22 bis 45:36 Minuten per `POST /v1/runs/<id>/stop`, obwohl sie Tools aufriefen und Dateien schrieben. Die Meldung „Hermes-Job abgebrochen." nannte keinen Grund. **Geändert:** - Neu `Iris/HermesRunLimits.swift` (nur Foundation): Schlüssel `hermesMaxRunMinutes`, Standard 45, Auswahl 30/45/60/120/240/480 Minuten, gespeicherte Werte werden auf 10 Minuten bis 24 Stunden begrenzt (ein Wert von Hand kann den Schutz nicht abschalten). - `HermesRunWatchdog`: liest die Grenze bei jeder Prüfung (gilt auch für laufende Läufe), merkt sich den Stoppgrund vor dem Stopp (`takeTripReason`). - `AgentJob`: die Meldung nach einem Watchdog-Stopp nennt den Grund und den Hinweis auf die Einstellung (vorher nur „abgebrochen"). - `CompanionPanelView`: Picker „Maximale Laufzeit“ unter Sonstiges; `Localizable.xcstrings` mit den deutschen Texten. - Silence-Timeout (10 Minuten ohne Ereignis) unverändert. Linux-Server hat keinen solchen Watchdog. **Geprüft:** Die Rechnung von `HermesRunLimits` mit `swiftc` und einem kleinen Testprogramm außerhalb der App (12 Prüfungen: Standard bei fehlendem Wert, Unter- und Obergrenze, Sekunden, Auswahlliste mit Sonderwert, Beschriftung, Meldung); mit ausgebauter Klammerung schlagen die Grenzfälle fehl. `swiftc -typecheck` über `HermesRunLimits`, `HermesRunWatchdog`, `HermesGatewayClient` und `IrisConfig`: keine Fehler in den geänderten Dateien (Fehler nur durch fehlende Nachbardateien). `Localizable.xcstrings` bleibt gültiges JSON. **Nicht geprüft:** Bauen der App (`xcodebuild` im Terminal ist ausgeschlossen, TCC); die Änderungen in `AgentJob.swift` und `CompanionPanelView.swift` wurden nicht typgeprüft und die Oberfläche nicht angesehen; ein echter Lauf über die Grenze (Stopp mit Grund) auf dem MacBook; dass der Picker einen Wert wirklich speichert und der Watchdog ihn beim nächsten Poll nutzt. Der Lauf auf dem MacBook läuft mit dem alten Build, bis dort ein neuer Build installiert ist. **Offen:** Weg 2 (fortschrittsbewusster Timer: nur Läufe stoppen, die keine neuen Ergebnisse liefern).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/Iris#333
No description provided.