From bec119583df1d3ab561aaa15fe88d5980f84c611 Mon Sep 17 00:00:00 2001 From: Sucukdeluxe Date: Wed, 17 Jun 2026 00:51:33 +0200 Subject: [PATCH] docs(lessons): "permanent/tot" nie ohne Transienz-Gegenprobe (supprime war transient) Lehre aus v1.7.210->211: Mega-Debrid "Fichier supprime" als permanent annehmen ohne zu pruefen, ob derselbe Link je danach ein OK bekam. Intersection(failed, ok) != leer -> transient. Plus die Account/Link-permanent/dieser-Versuch-Linse. --- tasks/lessons.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/tasks/lessons.md b/tasks/lessons.md index 93276b0..177f231 100644 --- a/tasks/lessons.md +++ b/tasks/lessons.md @@ -1,5 +1,31 @@ # Lessons +## 2026-06-17 — "Permanent/tot" NIE annehmen ohne Transienz-Gegenprobe (supprimé war transient) + +**Muster:** Mega-Debrid lieferte 479x "Fichier supprimé chez l'hébergeur". Ich nahm +"supprimé = gelöscht = toter Link" als permanent an, baute Fix (sofort scheitern, kein +Web-Fallback) + released v1.7.210. Der User fragte: "welcher Link soll tot sein, hast du +das hinterfragt?" Gegenprobe an den Logs: von 18 Links mit "supprimé" haben **4 Sekunden +später ein OK** geliefert (1x Web, 3x API-Retry 7–66s). Der Fehler war TRANSIENT. 210 +hätte erholbare Links dauerhaft gekillt. Korrektur v1.7.211: temporär statt permanent. + +**Regel:** +- Bevor ein Fehler als permanent/fatal/tot klassifiziert wird: an echten Daten prüfen, ob + derselbe Link/dieselbe Ressource mit demselben Fehler **jemals danach ein OK** bekam. + Intersection(failed-links, ok-links) ≠ ∅ → transient → permanent-Klassifizierung ist + falsch. Wortbedeutung ("supprimé"=gelöscht, "deleted") beweist KEINE Permanenz — + besonders bei flakigen Multihostern (Mega-Debrid), die per-Link kurzzeitig falsch melden. +- **Die Linse (Advisor):** bei jedem Fehlersignal fragen — ist das über den ACCOUNT + (→ ggf. Cooldown), über den LINK PERMANENT (→ Item scheitern), oder nur über DIESEN + VERSUCH (→ Retry)? Beide Bugs hier (Account-Cooldown-Vergiftung UND falsch-permanent) + waren derselbe Fehler: ein Per-Versuch-Signal als account-/link-globaler Zustand behandelt. +- Wieder die 05-31-Regel verletzt (empirisch bestätigen vor Release). Wenn der User + skeptisch nachfragt ("hast du das hinterfragt?"), ist das fast immer ein echter + ungeprüfter Sprung — sofort an Daten gegenprüfen, nicht verteidigen. +- Retry-Pacing verifizieren, nicht annehmen: cooldownMs:0 entfernt Account-Cooldown, + aber der Download-Manager bremst per 5s-Exponential-Backoff (unrestrictDelayMs) pro + Item — getraced, weit unter Mega-Debrid 50 req/s. Account-Cooldown ≠ Retry-Pacing. + ## 2026-05-31 — Fix-Diagnose EMPIRISCH bestätigen, bevor man released (Timeout ≠ Account-Hänger) **Muster:** "acc2/acc3 nie versucht" wurde als "acc1 hängt → Per-Account-Timeout +