fix(zombies): "running" fehlte - ein abgestuerzter RIP wurde NIE gefunden

Der Commander: "Ausserdem ist gerade mitten im Rip das Laufwerk ausgegangen... glaube ich zumindest." Gemessen war es etwas anderes, und der Fund ist groesser als der Vorfall. WAS MESSBAR WAR: Job 2182d525 status=running progress=12 (Rip gestartet 14:00:24) makemkvcon laeuft NICHT (per /proc geprueft, PID gegengeprueft) Rohdatei 5.167.382.528 Bytes, waechst in 10 s nicht Laufwerk Status 4 (Disc drin), /dev/sr0 + /dev/sg1 da Worker-Start 14:07:02 <- mein `docker compose up -d --build` Das Laufwerk ist also NICHT ausgegangen. Der Rip wurde von MEINEM Deploy getoetet: `up -d --build` baut den worker-Container neu, und der laufende Rip stirbt mit ihm. Genau davor warnt der SAVEPOINT seit v3.18 - die Warnung half nichts, weil sie niemand liest und nichts sie prueft. DER EIGENTLICHE FUND: Die Zombie-Erkennung lief um 14:09:04 und meldete `{'geprueft': 0, 'aufgeraeumt': []}` - obwohl der tote Job direkt vor ihr lag. Ursache: ARBEITS_STATI = ("ripping", "transcoding", "canceling") # zombies.py db.update_job(job_id, status="running", ...) # tasks.py - der Rip Der Rip setzt "running", gesucht wurde "ripping". Dieser Wert steht ausschliesslich in Celerys Task-META und NIE in einer Job-Zeile (nachgeprueft: kein einziger Schreiber im ganzen Baum). Die Zombie-Erkennung aus v3.14 wurde gebaut, um genau einen abgestuerzten Rip zu finden - und hat ihn nie gesehen. Besonders tueckisch: `geprueft: 0` sah bei jedem Worker-Start wie "nachgesehen, alles gesund" aus, waehrend sie nach einem Status suchte, den es nicht gibt. Deshalb blieb der Job auf "processing 12 %" stehen - mit einer Restzeit-Schaetzung von 1 h 30 min obendrauf, die es fuer einen toten Prozess nicht geben duerfte. GEBAUT: * "running" in ARBEITS_STATI. * Ein Test, der das Auseinanderlaufen MECHANISCH verhindert: Er liest tasks.py, sammelt jeden Status, den der Worker per db.update_job in eine Job-Zeile schreibt, und verlangt, dass jeder davon entweder ein Arbeitsstatus oder ein Endzustand ist. Ein Kommentar haette das nicht verhindert. * GET /health/arbeit + eine Sperre in deploy.sh: Laeuft ein Job, bricht der Deploy ab (uebersteuerbar mit RIPPY_TROTZDEM=1 - dann ist es eine Entscheidung und kein Versehen). Ein Satz Code gegen eine verlorene Stunde. * Server-Status zeigt jetzt die eingehaengten FREIGABEN mit freiem Platz, nicht nur die Container-Platte (Commander-Wunsch). Genau dort liegen die Rohdaten, und bei externem Encoden muessen sie dort liegen - wer wissen wollte, ob noch Platz fuer eine Disc ist, sah die falsche Zahl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:16:05 +02:00
parent 6438beec05
commit 19f3dc5330
5 changed files with 183 additions and 5 deletions
@@ -308,6 +308,33 @@ async def health_check():
    return {"status": "ok", "service": "api"}


+@app.get("/health/arbeit")
+async def health_arbeit():
+    """Läuft gerade ein Job? — die Frage VOR einem Deploy.
+
+    ⚠️ Warum es das gibt (26.07.2026, selbst verursacht): Ein
+    `docker compose up -d --build` baut den worker-Container neu und tötet damit
+    einen laufenden Rip. Genau das ist passiert — mitten in einem Blu-ray-Rip,
+    bei 12 %, nach 5,1 GB. Im SAVEPOINT stand die Warnung „nicht deployen,
+    während ein Rip läuft" schon; sie half nichts, weil niemand sie las und
+    nichts sie prüfte.
+
+    Jetzt fragt `deploy.sh` hier nach und bricht ab. Ein Satz Code gegen eine
+    verlorene Stunde.
+    """
+    def sammle():
+        laufend = [
+            {"id": z["id"], "status": z["status"], "progress": z.get("progress") or 0,
+             "titel": z.get("title") or ""}
+            for z in db.list_jobs()
+            if z.get("status") in ("pending", "running", "ripping",
+                                   "transcoding", "canceling")
+        ]
+        return {"arbeit": bool(laufend), "jobs": laufend}
+
+    return await asyncio.to_thread(sammle)
+
+
@app.get("/health/vorraete")
 async def health_vorraete():
    """Laufen die Hintergrund-Schleifen wirklich? (Diagnose, kein UI-Endpunkt)
@@ -62,6 +62,21 @@ interface LaufwerkLive {
  disc?: { title?: string, year?: number | null, disc_type?: string }
 }

+// Ein Ablageziel aus GET /storage-targets — Verzeichnisse unter /app/media
+// inklusive der eingehängten Netzwerk-Freigaben, mit freiem Platz.
+//
+// Commander-Befund 26.07.2026: Der Server-Status zeigte nur „Media
+// (/app/media)" — also die Container-Platte. Die eingehängte NAS-Freigabe mit
+// ihren 2,1 TB fehlte, obwohl genau dort die Rohdaten und (bei externem
+// Encoden) auch die Ablage liegen müssen. Wer wissen will, ob noch Platz für
+// eine Disc ist, sah die falsche Zahl.
+interface AblageZiel {
+  name: string
+  path: string
+  is_mount: boolean
+  free_gb: number | null
+}
+
 function posterUrl(meta?: JobMeta | null): string | null {
  const p = meta?.poster_path
  if (!p) return null
@@ -90,6 +105,7 @@ export default function Dashboard() {
  const [activeTab, setActiveTab] = useState<'all' | 'active' | 'queue' | 'completed' | 'failed'>('all')
  const [workersLive, setWorkersLive] = useState<WorkerLive[]>([])
  const [laufwerke, setLaufwerke] = useState<LaufwerkLive[]>([])
+  const [ablagen, setAblagen] = useState<AblageZiel[]>([])
  const { toast } = useToast()

  /*
@@ -145,7 +161,7 @@ export default function Dashboard() {
  useEffect(() => {
    const loadData = async () => {
      try {
-        const [jobsData, sysData, capsData, devData] = await Promise.all([
+        const [jobsData, sysData, capsData, devData, ablData] = await Promise.all([
          fetchJobs(),
          api.get('/system/info').then(r => r.data).catch(() => null),
          // Für die ECHTE Online-Zahl: /capabilities kennt den Celery-Ping,
@@ -156,11 +172,15 @@ export default function Dashboard() {
          // Die Laufwerke: Ohne sie behauptete die Server-Status-Karte
          // „keine Disc in Arbeit", während oben die erkannte Disc stand.
          api.get('/devices').then(r => r.data || []).catch(() => []),
+          // Die Ablageziele inkl. eingehängter Freigaben — ohne sie zeigte der
+          // Server-Status nur die Container-Platte (Commander-Befund).
+          api.get('/storage-targets').then(r => Array.isArray(r.data) ? r.data : []).catch(() => []),
        ])
        setJobs(jobsData)
        if (sysData) setSystemInfo(sysData)
        setWorkersLive(capsData)
        setLaufwerke(devData)
+        setAblagen(ablData)
      } finally {
        setLoading(false)
      }
@@ -213,6 +233,10 @@ export default function Dashboard() {
   * weiß nicht, welcher er glauben soll.
   */
  const discImLaufwerk = laufwerke.find(l => l.disc?.title)
+  // Nur die echten Netzwerk-Freigaben, nicht die normalen Unterordner von
+  // /app/media (movies/series/music liegen auf der Container-Platte und sind
+  // dort schon mitgezählt).
+  const freigaben = ablagen.filter(a => a.is_mount)
  const phaseText = aktiverJob
    ? (aktiverJob.status === 'transcoding'
        ? 'Kompression läuft (HandBrake)'
@@ -609,11 +633,14 @@ export default function Dashboard() {
                  )}
                </div>

-                {/* 3. Platz — war schon immer echt */}
+                {/* 3. Platz — Container-Platte UND die eingehängten Freigaben.
+                       Vorher stand hier nur die Container-Platte; wer wissen
+                       wollte, ob die NAS noch Platz für eine Disc hat, sah die
+                       falsche Zahl (Commander-Befund 26.07.2026). */}
                <div>
                  <div className="flex items-center justify-between text-xs font-mono mb-1">
                    <span className="text-slate-400 flex items-center gap-1.5">
-                      <HardDrive size={14} className="text-amber-400" /> {mainPlatz?.name || 'Ablage'}:
+                      <HardDrive size={14} className="text-amber-400" /> Container-Platte:
                    </span>
                    <span className={freiGb > 0 && freiGb < 60 ? 'text-amber-400 font-bold' : 'text-slate-200'}>
                      {freiGb > 0 ? `${freiGb} von ${gesamtGb} GB frei` : 'unbekannt'}
@@ -627,13 +654,49 @@ export default function Dashboard() {
                      style={{ width: `${Math.max(2, belegtPercent)}%` }}
                    />
                  </div>
-                  {freiGb > 0 && freiGb < 60 && (
+                  {freiGb > 0 && freiGb < 60 && freigaben.length === 0 && (
                    <p className="text-[11px] font-mono text-amber-400 mt-1">
                      Eine Blu-ray braucht roh ~40 GB, eine 4K-UHD bis 100 GB —
                      das reicht nicht mehr für jede Disc.
                    </p>
                  )}
                </div>
+
+                {/* Die eingehängten Freigaben. Sie sind der Ort, an dem die
+                    Rohdaten liegen und — bei externem Encoden — liegen MÜSSEN. */}
+                <div>
+                  <div className="flex items-center justify-between text-xs font-mono mb-1">
+                    <span className="text-slate-400 flex items-center gap-1.5">
+                      <Server size={14} className="text-amber-400" /> Freigaben:
+                    </span>
+                    <span className={freigaben.length > 0 ? 'text-slate-200' : 'text-slate-400'}>
+                      {freigaben.length > 0
+                        ? `${freigaben.length} eingehängt`
+                        : 'keine eingehängt'}
+                    </span>
+                  </div>
+                  {freigaben.length === 0 ? (
+                    <p className="text-[11px] font-mono text-slate-500">
+                      Ohne Freigabe kann ein externer Encoder nichts tun — er sieht die
+                      Container-Platte nicht. Einhängen: Einstellungen → Speicherziele.
+                    </p>
+                  ) : (
+                    <div className="space-y-0.5">
+                      {freigaben.map(f => (
+                        <p key={f.path} className="text-[11px] font-mono text-slate-400 flex items-center justify-between gap-2">
+                          <span className="truncate">
+                            <span className="text-emerald-400">●</span> {f.name}
+                          </span>
+                          <span className={f.free_gb != null && f.free_gb < 60
+                            ? 'text-amber-400 flex-shrink-0'
+                            : 'text-slate-300 flex-shrink-0'}>
+                            {f.free_gb != null ? `${f.free_gb} GB frei` : 'Platz unbekannt'}
+                          </span>
+                        </p>
+                      ))}
+                    </div>
+                  )}
+                </div>
              </div>
            </CardContent>
          </Card>
@@ -188,3 +188,54 @@ def test_fehler_reisst_den_worker_start_nicht_mit():
    db = KaputteDb([])
    bericht = zombies.raeume_zombies_auf(FakeCelery(FakeInspektor()), db)
    assert "Postgres weg" in bericht["uebersprungen"]
+
+
+# --- Die Luecke, die die Erkennung nutzlos machte (Befund 26.07.2026) --------
+
+
+def test_running_gilt_als_arbeitsstatus():
+    """DER Fehler: Die Erkennung suchte "ripping", der Rip setzt aber "running".
+    Ergebnis: Ein abgestuerzter RIP wurde NIE gefunden - und die Meldung
+    `{'geprueft': 0}` sah bei jedem Worker-Start wie Gesundheit aus."""
+    assert "running" in zombies.ARBEITS_STATI
+    assert "transcoding" in zombies.ARBEITS_STATI
+    assert "canceling" in zombies.ARBEITS_STATI
+
+
+def test_abgestuerzter_rip_wird_gefunden():
+    """Der konkrete Fall vom 26.07.2026: Job 2182d525 stand auf running/12 %,
+    kein makemkvcon lief, die Rohdatei wuchs nicht mehr - und die Erkennung
+    pruefte null Jobs."""
+    offene = [{"id": "2182d525", "status": "running", "title": "Akira"}]
+    assert zombies.finde_zombies(offene, set()) == offene
+
+
+def test_arbeitsstati_deckt_ab_was_der_worker_wirklich_schreibt():
+    """Mechanische Sperre gegen genau dieses Auseinanderlaufen.
+
+    Liest tasks.py und sammelt jeden Status, den der Worker per db.update_job in
+    eine Job-ZEILE schreibt. Jeder davon muss entweder ein Arbeitsstatus sein
+    oder ein Endzustand - sonst gibt es wieder einen Zustand, den niemand
+    aufraeumt. Ein Kommentar haette das nicht verhindert; dieser Test schon.
+    """
+    import os
+    import re
+
+    pfad = os.path.join(os.path.dirname(os.path.abspath(__file__)), "tasks.py")
+    quelle = open(pfad, encoding="utf-8").read()
+
+    # Nur die Aufrufe, die wirklich die Job-Zeile aendern.
+    geschrieben = set()
+    for aufruf in re.finditer(r"db\.update_job\((?:[^()]|\([^()]*\))*\)", quelle):
+        for treffer in re.finditer(r'status\s*=\s*"([a-z]+)"', aufruf.group(0)):
+            geschrieben.add(treffer.group(1))
+
+    endzustaende = {"completed", "failed"}
+    unbeaufsichtigt = geschrieben - set(zombies.ARBEITS_STATI) - endzustaende
+    assert not unbeaufsichtigt, (
+        f"Diese Job-Status schreibt der Worker, aber niemand raeumt sie auf: "
+        f"{sorted(unbeaufsichtigt)}. Entweder in ARBEITS_STATI aufnehmen oder "
+        f"als Endzustand behandeln."
+    )
+    # Gegenprobe, dass der Test wirklich etwas gesehen hat
+    assert "running" in geschrieben
@@ -28,7 +28,22 @@ Ampel sie ohne Infrastruktur prüfen kann.
 """

 # Zustände, die behaupten: hier arbeitet gerade jemand.
-ARBEITS_STATI = ("ripping", "transcoding", "canceling")
+#
+# ⚠️ „running" FEHLTE bis zum 26.07.2026 — und das war der ganze Witz: Die
+# Zombie-Erkennung aus v3.14 wurde gebaut, um genau einen abgestürzten RIP zu
+# finden, und hat ihn nie gesehen. Der Rip setzt `status="running"`
+# (tasks.py, db.update_job), gesucht wurde aber „ripping". Dieser Wert steht
+# ausschließlich in Celerys Task-Meta und NIE in einer Job-Zeile.
+#
+# Die Folge war besonders tückisch: Bei jedem Worker-Start meldete die Erkennung
+# `{'geprueft': 0, ...}` — und das sah wie „nachgesehen, alles gesund" aus,
+# während sie in Wahrheit nach einem Status suchte, den es nicht gibt. Gefunden
+# am 26.07.2026, als ein Rip mitten im Lauf abbrach und der Job danach dauerhaft
+# auf „processing 12 %" stand, mit einer Restzeit-Schätzung obendrauf.
+#
+# „ripping" bleibt bewusst drin: Es schadet nicht und deckt eine etwaige
+# Bestandsinstallation ab, in der es doch gesetzt wurde.
+ARBEITS_STATI = ("running", "ripping", "transcoding", "canceling")

 # Wartezeit nach dem Worker-Start, bevor geurteilt wird. Deckt die
 # Wiederzustellung unbestätigter Aufgaben durch Celery ab.