Tasks bleiben stuck trotz aktiver Workers #340

New issue

Closed

opened 2026-03-02 13:37:11 +00:00 by jack · 0 comments

jack commented

2026-03-02 13:37:11 +00:00

Owner

Problem

Symptom: Tasks bleiben manchmal hängen und werden nicht verarbeitet, obwohl Workers connected sind.

Sichtbar in UI:

"3 workers" angezeigt (grün, connected)
"Connected" Status aktiv
Tasks werden aber nicht completed

Mögliche Ursachen

Race Conditions beim Task-Assignment
Deadlocks bei Worker-Locks
Fehlerhafte Retry-Logic bei fehlgeschlagenen Tasks
Memory Leaks in Worker-Prozessen
Fehlende Timeouts für Task-Completion

Erwartetes Verhalten

Tasks sollten von verfügbaren Workers automatisch verarbeitet werden
Bei Fehlern: Retry oder Error-State (nicht stuck)
Stuck-Detection und Auto-Recovery nach Timeout

Technische Details

Zu prüfen:

Task-Queue-Implementation (Redis? Memory? DB?)
Worker-Assignment-Logic
Lock-Mechanismus (distributed locks?)
Timeout-Handling
Error-Recovery-Strategy

Logs/Monitoring:

Worker-Heartbeats prüfen
Task-State-Transitions tracken
Stuck-Task-Detection implementieren

Lösungsansätze

Stuck-Task-Detection: Background-Job der Tasks >5min in "processing" findet
Auto-Recovery: Stuck-Tasks nach Timeout zurück in Queue
Worker-Heartbeats: Workers müssen regelmäßig Lebenszeichen geben
Better Logging: Task-State-Transitions komplett loggen
Distributed Locks: Sicherstellen dass Locks nicht verloren gehen

Vermutlich connected zu UI-State-Inkonsistenzen (#327-#334)
Queue-Implementation sollte robust sein gegen diese Edge-Cases

## Problem **Symptom:** Tasks bleiben manchmal hängen und werden nicht verarbeitet, obwohl Workers connected sind. **Sichtbar in UI:** - "3 workers" angezeigt (grün, connected) - "Connected" Status aktiv - Tasks werden aber nicht completed ## Mögliche Ursachen 1. **Race Conditions** beim Task-Assignment 2. **Deadlocks** bei Worker-Locks 3. **Fehlerhafte Retry-Logic** bei fehlgeschlagenen Tasks 4. **Memory Leaks** in Worker-Prozessen 5. **Fehlende Timeouts** für Task-Completion ## Erwartetes Verhalten - Tasks sollten von verfügbaren Workers automatisch verarbeitet werden - Bei Fehlern: Retry oder Error-State (nicht stuck) - Stuck-Detection und Auto-Recovery nach Timeout ## Technische Details **Zu prüfen:** - Task-Queue-Implementation (Redis? Memory? DB?) - Worker-Assignment-Logic - Lock-Mechanismus (distributed locks?) - Timeout-Handling - Error-Recovery-Strategy **Logs/Monitoring:** - Worker-Heartbeats prüfen - Task-State-Transitions tracken - Stuck-Task-Detection implementieren ## Lösungsansätze 1. **Stuck-Task-Detection:** Background-Job der Tasks >5min in "processing" findet 2. **Auto-Recovery:** Stuck-Tasks nach Timeout zurück in Queue 3. **Worker-Heartbeats:** Workers müssen regelmäßig Lebenszeichen geben 4. **Better Logging:** Task-State-Transitions komplett loggen 5. **Distributed Locks:** Sicherstellen dass Locks nicht verloren gehen ## Related - Vermutlich connected zu UI-State-Inkonsistenzen (#327-#334) - Queue-Implementation sollte robust sein gegen diese Edge-Cases