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

New issue

Closed

opened 2026-01-24 09:25:36 +00:00 by jack · 0 comments

jack commented

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

Owner

Problem

Die Worker-Termination-Logik hat mehrere Bugs:

1. Busy-Check wird übersprungen wenn `connectedWorkerId` undefined ist

In packages/backend/src/routes/workers.ts:204-217:

const hubWorkerId = spawnedWorker!.connectedWorkerId;

// Check if worker is busy
if (hubWorkerId && this.deps.workerHub.isWorkerBusy(hubWorkerId)) {
  // ... queue for termination
}

Problem: Wenn der Worker noch nicht mit dem WorkerHub verbunden ist (z.B. gerade erst gestartet oder Verbindung verloren), ist connectedWorkerId = undefined. In diesem Fall wird die isWorkerBusy() Prüfung komplett übersprungen und der Worker wird direkt terminiert - auch wenn er gerade arbeitet!

2. Worker-ID-Nummerierung ist verwirrend

Der WorkerHub verwendet einen eigenen Counter für Worker-IDs:

// worker-hub.ts:31
private workerCounter = 0;

// worker-hub.ts:76
const workerId = `worker-${++this.workerCounter}-${Date.now()}`;

Wenn Worker disconnecten und reconnecten, oder wenn ein Worker gelöscht wird und ein neuer gestartet wird, können die IDs für den Benutzer verwirrend erscheinen:

Worker-4 wird gelöscht
Neuer Worker verbindet als Worker-5
Im UI sieht es aus, als hätte sich "der Worker" geändert

Lösungsvorschlag

Fix 1: Robustere Busy-Prüfung

// In workers.ts terminateWorker()

// Check if worker is busy - even if not connected to hub yet
const hubWorkerId = spawnedWorker!.connectedWorkerId;

// Option A: Always queue if worker status is not idle
if (spawnedWorker!.status === 'running') {
  // Check hub connection for definitive busy state
  if (hubWorkerId && this.deps.workerHub.isWorkerBusy(hubWorkerId)) {
    // Queue termination - worker is definitely busy
    this.deps.workerHub.markForTermination(hubWorkerId);
    this.deps.workerProcessManager!.queueTermination(id);
    return { queued: true };
  }
  
  // No hub connection but process is running - still queue
  if (!hubWorkerId) {
    this.deps.workerProcessManager!.queueTermination(id);
    return { queued: true, reason: 'Worker not yet connected, queued for safety' };
  }
}

Fix 2: Stabilere Worker-Anzeige

Optionen:

A) Spawned-ID als primäre Anzeige verwenden (z.B. spawned-1, spawned-2)
B) Feste Slot-Nummerierung (Worker Slot 1, 2, 3...) unabhängig von der internen ID
C) Nur die Provider-Info anzeigen statt ID (Mistral Worker, Gemini Worker)

Betroffene Dateien

Datei	Änderung
`packages/backend/src/routes/workers.ts`	Robustere Busy-Prüfung
`packages/backend/src/services/worker-process-manager.ts`	Status-Check bei Termination
`packages/ui/src/components/WorkerStatus.tsx`	Stabilere ID-Anzeige

Akzeptanzkriterien

Worker wird nie sofort terminiert wenn er gerade einen Task bearbeitet
Auch ohne Hub-Verbindung wird Termination gequeued wenn Worker "running" ist
Worker-IDs/Anzeige im UI bleibt stabil und verwirrrt nicht

## Problem Die Worker-Termination-Logik hat mehrere Bugs: ### 1. Busy-Check wird übersprungen wenn `connectedWorkerId` undefined ist In `packages/backend/src/routes/workers.ts:204-217`: ```typescript const hubWorkerId = spawnedWorker!.connectedWorkerId; // Check if worker is busy if (hubWorkerId && this.deps.workerHub.isWorkerBusy(hubWorkerId)) { // ... queue for termination } ``` **Problem:** Wenn der Worker noch nicht mit dem WorkerHub verbunden ist (z.B. gerade erst gestartet oder Verbindung verloren), ist `connectedWorkerId = undefined`. In diesem Fall wird die `isWorkerBusy()` Prüfung komplett übersprungen und der Worker wird direkt terminiert - auch wenn er gerade arbeitet! ### 2. Worker-ID-Nummerierung ist verwirrend Der `WorkerHub` verwendet einen eigenen Counter für Worker-IDs: ```typescript // worker-hub.ts:31 private workerCounter = 0; // worker-hub.ts:76 const workerId = `worker-${++this.workerCounter}-${Date.now()}`; ``` Wenn Worker disconnecten und reconnecten, oder wenn ein Worker gelöscht wird und ein neuer gestartet wird, können die IDs für den Benutzer verwirrend erscheinen: - Worker-4 wird gelöscht - Neuer Worker verbindet als Worker-5 - Im UI sieht es aus, als hätte sich "der Worker" geändert ## Lösungsvorschlag ### Fix 1: Robustere Busy-Prüfung ```typescript // In workers.ts terminateWorker() // Check if worker is busy - even if not connected to hub yet const hubWorkerId = spawnedWorker!.connectedWorkerId; // Option A: Always queue if worker status is not idle if (spawnedWorker!.status === 'running') { // Check hub connection for definitive busy state if (hubWorkerId && this.deps.workerHub.isWorkerBusy(hubWorkerId)) { // Queue termination - worker is definitely busy this.deps.workerHub.markForTermination(hubWorkerId); this.deps.workerProcessManager!.queueTermination(id); return { queued: true }; } // No hub connection but process is running - still queue if (!hubWorkerId) { this.deps.workerProcessManager!.queueTermination(id); return { queued: true, reason: 'Worker not yet connected, queued for safety' }; } } ``` ### Fix 2: Stabilere Worker-Anzeige Optionen: - **A)** Spawned-ID als primäre Anzeige verwenden (z.B. `spawned-1`, `spawned-2`) - **B)** Feste Slot-Nummerierung (Worker Slot 1, 2, 3...) unabhängig von der internen ID - **C)** Nur die Provider-Info anzeigen statt ID (`Mistral Worker`, `Gemini Worker`) ## Betroffene Dateien | Datei | Änderung | |-------|----------| | `packages/backend/src/routes/workers.ts` | Robustere Busy-Prüfung | | `packages/backend/src/services/worker-process-manager.ts` | Status-Check bei Termination | | `packages/ui/src/components/WorkerStatus.tsx` | Stabilere ID-Anzeige | ## Akzeptanzkriterien - [ ] Worker wird nie sofort terminiert wenn er gerade einen Task bearbeitet - [ ] Auch ohne Hub-Verbindung wird Termination gequeued wenn Worker "running" ist - [ ] Worker-IDs/Anzeige im UI bleibt stabil und verwirrrt nicht