Worker Auto-Spawn verbessern und Docker-Zuverlässigkeit sicherstellen

No labels

No milestone

No project

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.

Depends on

#120 Worker-Löschlogik: Busy-Check wird übersprungen wenn Worker noch nicht verbunden

customable/claude-mem

Reference

customable/claude-mem#118

jack commented

2026-01-24 09:22:14 +00:00

Owner

Problem

Das Worker Auto-Spawn System existiert bereits (packages/backend/src/server/backend-service.ts:410-440), funktioniert aber nicht zuverlässig. Außerdem sollte es für Docker-Deployments robuster gemacht werden.

Aktuelle Limitierungen

Auto-Spawn standardmäßig deaktiviert
- AUTO_SPAWN_WORKERS ist per Default false
- Benutzer müssen es manuell aktivieren
Keine automatische Worker-Recovery
- Wenn ein Worker abstürzt (status: 'crashed'), wird er nicht automatisch neu gestartet
- Nur beim initialen Backend-Start werden Worker gespawnt
- Code-Referenz: worker-process-manager.ts:226-234 - Exit-Handler setzt nur Status
Worker Binary Detection fragil
- Multiple Fallback-Pfade (worker-process-manager.ts:67-94)
- Bei Plugin-Installation nicht immer korrekt gefunden
- canSpawnWorkers() kann fehlschlagen ohne klare Fehlermeldung
Docker-spezifische Probleme
- Worker muss auf Backend-Health warten (depends_on reicht nicht immer)
- WebSocket-Verbindung kann bei Netzwerkproblemen fehlschlagen ohne Retry
- Kein Health-Endpoint für Worker selbst

Gewünschte Verbesserungen

Phase 1: Zuverlässiges Auto-Spawn

Auto-Spawn per Default aktivieren (oder zumindest besser dokumentieren)

Automatische Worker-Recovery implementieren:

// Bei Worker-Exit prüfen ob Restart nötig
if (exitCode !== 0 && this.autoRestartEnabled) {
  setTimeout(() => this.spawn(provider), RESTART_DELAY);
}

Konfigurierbare Restart-Policy: never, on-failure, always
Max-Restart-Counter mit Backoff (um Crash-Loops zu verhindern)

Phase 2: Docker-Zuverlässigkeit

Health-Endpoint für Worker (/health oder via WebSocket-Heartbeat)
Robustere WebSocket-Reconnection-Logik im Worker
Docker-Compose Health-Check für Worker-Container
Dokumentation für Kubernetes/Docker Swarm Deployments
Startup-Probe vs Liveness-Probe Unterscheidung

Phase 3: Monitoring & Observability

Worker-Status in UI anzeigen (aktuell nur über API)
Metriken für Worker-Restarts, Task-Durchsatz
Alerts bei Worker-Ausfall (optional, via Webhook)

Technische Details

Betroffene Dateien

Datei	Änderungen
`packages/backend/src/server/backend-service.ts`	Auto-Spawn Logik erweitern
`packages/backend/src/services/worker-process-manager.ts`	Recovery-Logik, Health-Checks
`packages/shared/src/settings.ts`	Neue Settings für Restart-Policy
`packages/worker/src/worker-service.ts`	Health-Endpoint, Reconnection
`docker-compose.yml`	Worker Health-Check
`Dockerfile.worker`	Health-Check Command

Neue Settings (Vorschlag)

WORKER_RESTART_POLICY: 'never' | 'on-failure' | 'always' = 'on-failure',
WORKER_MAX_RESTARTS: number = 5,
WORKER_RESTART_DELAY_MS: number = 3000,
WORKER_RESTART_BACKOFF_MULTIPLIER: number = 2,

Akzeptanzkriterien

Worker werden automatisch neu gestartet bei Crash (konfigurierbar)
Docker-Deployments funktionieren zuverlässig ohne manuelle Intervention
Worker-Status ist im UI sichtbar
Crash-Loops werden erkannt und verhindert (Max-Restarts mit Backoff)

## Problem Das Worker Auto-Spawn System existiert bereits (`packages/backend/src/server/backend-service.ts:410-440`), funktioniert aber nicht zuverlässig. Außerdem sollte es für Docker-Deployments robuster gemacht werden. ### Aktuelle Limitierungen 1. **Auto-Spawn standardmäßig deaktiviert** - `AUTO_SPAWN_WORKERS` ist per Default `false` - Benutzer müssen es manuell aktivieren 2. **Keine automatische Worker-Recovery** - Wenn ein Worker abstürzt (`status: 'crashed'`), wird er nicht automatisch neu gestartet - Nur beim initialen Backend-Start werden Worker gespawnt - Code-Referenz: `worker-process-manager.ts:226-234` - Exit-Handler setzt nur Status 3. **Worker Binary Detection fragil** - Multiple Fallback-Pfade (`worker-process-manager.ts:67-94`) - Bei Plugin-Installation nicht immer korrekt gefunden - `canSpawnWorkers()` kann fehlschlagen ohne klare Fehlermeldung 4. **Docker-spezifische Probleme** - Worker muss auf Backend-Health warten (`depends_on` reicht nicht immer) - WebSocket-Verbindung kann bei Netzwerkproblemen fehlschlagen ohne Retry - Kein Health-Endpoint für Worker selbst ## Gewünschte Verbesserungen ### Phase 1: Zuverlässiges Auto-Spawn - [ ] Auto-Spawn per Default aktivieren (oder zumindest besser dokumentieren) - [ ] Automatische Worker-Recovery implementieren: ```typescript // Bei Worker-Exit prüfen ob Restart nötig if (exitCode !== 0 && this.autoRestartEnabled) { setTimeout(() => this.spawn(provider), RESTART_DELAY); } ``` - [ ] Konfigurierbare Restart-Policy: `never`, `on-failure`, `always` - [ ] Max-Restart-Counter mit Backoff (um Crash-Loops zu verhindern) ### Phase 2: Docker-Zuverlässigkeit - [ ] Health-Endpoint für Worker (`/health` oder via WebSocket-Heartbeat) - [ ] Robustere WebSocket-Reconnection-Logik im Worker - [ ] Docker-Compose Health-Check für Worker-Container - [ ] Dokumentation für Kubernetes/Docker Swarm Deployments - [ ] Startup-Probe vs Liveness-Probe Unterscheidung ### Phase 3: Monitoring & Observability - [ ] Worker-Status in UI anzeigen (aktuell nur über API) - [ ] Metriken für Worker-Restarts, Task-Durchsatz - [ ] Alerts bei Worker-Ausfall (optional, via Webhook) ## Technische Details ### Betroffene Dateien | Datei | Änderungen | |-------|------------| | `packages/backend/src/server/backend-service.ts` | Auto-Spawn Logik erweitern | | `packages/backend/src/services/worker-process-manager.ts` | Recovery-Logik, Health-Checks | | `packages/shared/src/settings.ts` | Neue Settings für Restart-Policy | | `packages/worker/src/worker-service.ts` | Health-Endpoint, Reconnection | | `docker-compose.yml` | Worker Health-Check | | `Dockerfile.worker` | Health-Check Command | ### Neue Settings (Vorschlag) ```typescript WORKER_RESTART_POLICY: 'never' | 'on-failure' | 'always' = 'on-failure', WORKER_MAX_RESTARTS: number = 5, WORKER_RESTART_DELAY_MS: number = 3000, WORKER_RESTART_BACKOFF_MULTIPLIER: number = 2, ``` ## Akzeptanzkriterien - [ ] Worker werden automatisch neu gestartet bei Crash (konfigurierbar) - [ ] Docker-Deployments funktionieren zuverlässig ohne manuelle Intervention - [ ] Worker-Status ist im UI sichtbar - [ ] Crash-Loops werden erkannt und verhindert (Max-Restarts mit Backoff)

jack added the

labels

2026-01-24 09:22:16 +00:00

jack added a new dependency

2026-01-24 09:25:46 +00:00

jonas.hanisch referenced this issue from a commit

2026-01-24 22:01:42 +00:00

feat(worker): implement auto-restart for crashed workers (#118)

jonas.hanisch closed this issue

2026-01-24 22:17:53 +00:00