Watchdog verbessern: Dynamisches Timeout statt starrer 15-Minuten-Cutoff #45

New issue

Open

opened 2026-03-30 19:55:50 +00:00 by David · 0 comments

David commented

2026-03-30 19:55:50 +00:00

Collaborator

Beschreibung

Der Watchdog-Job hat einen fixen 15-Minuten-Cutoff. Legitime lange Runs werden fälschlich gekillt, und Jobs die bei 14:59 steckenbleiben werden nicht erkannt.

Hintergrund

main.py:69-93 markiert alle Tickets mit Status running/scoring/preparing als failed wenn started_at älter als 15 Minuten ist. Das ist problematisch:

Claude Code Timeout ist 600s (10 min), aber mit Review-Loops und Git-Ops kann ein Run legitimerweise >15 min dauern
Ein Ticket das bei 14:59 steckt wird erst nach 5 weiteren Minuten (nächster Watchdog-Run) erkannt

Akzeptanzkriterien

Watchdog-Timeout ist pro Status unterschiedlich: scoring (5 min), preparing (10 min), running (konfigurierbar, Default: Claude-Timeout × 1.5)
Ticket speichert last_heartbeat Timestamp der bei Pipeline-Fortschritt aktualisiert wird
Watchdog prüft last_heartbeat statt nur started_at
Bei Timeout: Logging mit Details (welcher Status, wie lange, letzter Heartbeat)
Konfigurierbar: WATCHDOG_TIMEOUT_MULTIPLIER

Technische Hinweise

Fix in: backend/main.py — Watchdog-Logik erweitern
Erweitern: backend/models/ticket.py — last_heartbeat (DateTime)
Erweitern: backend/services/pipeline.py — Heartbeat bei jedem Stage-Übergang setzen
Migration nötig: ja (neues Feld last_heartbeat)

Aufwand: S

## Beschreibung Der Watchdog-Job hat einen fixen 15-Minuten-Cutoff. Legitime lange Runs werden fälschlich gekillt, und Jobs die bei 14:59 steckenbleiben werden nicht erkannt. ## Hintergrund `main.py:69-93` markiert alle Tickets mit Status `running/scoring/preparing` als `failed` wenn `started_at` älter als 15 Minuten ist. Das ist problematisch: - Claude Code Timeout ist 600s (10 min), aber mit Review-Loops und Git-Ops kann ein Run legitimerweise >15 min dauern - Ein Ticket das bei 14:59 steckt wird erst nach 5 weiteren Minuten (nächster Watchdog-Run) erkannt ## Akzeptanzkriterien - [ ] Watchdog-Timeout ist pro Status unterschiedlich: `scoring` (5 min), `preparing` (10 min), `running` (konfigurierbar, Default: Claude-Timeout × 1.5) - [ ] Ticket speichert `last_heartbeat` Timestamp der bei Pipeline-Fortschritt aktualisiert wird - [ ] Watchdog prüft `last_heartbeat` statt nur `started_at` - [ ] Bei Timeout: Logging mit Details (welcher Status, wie lange, letzter Heartbeat) - [ ] Konfigurierbar: `WATCHDOG_TIMEOUT_MULTIPLIER` ## Technische Hinweise - Fix in: `backend/main.py` — Watchdog-Logik erweitern - Erweitern: `backend/models/ticket.py` — `last_heartbeat` (DateTime) - Erweitern: `backend/services/pipeline.py` — Heartbeat bei jedem Stage-Übergang setzen - Migration nötig: ja (neues Feld `last_heartbeat`) ## Aufwand: S