Administrator/real-debrid-downloader
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 512 Wiki Activity
dfd19260f6
real-debrid-downloader/tasks/audit-loop.md
Sucukdeluxe c8ea2f6765 Fix: Startup-Dedup ersetzt keine gute kanonische Datei mehr durch ein kleineres Duplikat 
Beim Start gleicht das Tool Duplikat-benannte Dateien ("Name (1).ext") gegen die
kanonische Datei ("Name.ext") ab. Im Zweig "Duplikat rangiert hoeher und das
kanonische Item ist nicht 'completed'" wurde bisher bedingungslos
fs.rmSync(kanonisch) + fs.renameSync(Duplikat → kanonisch) ausgefuehrt — ohne die
echten Dateigroessen zu vergleichen. Der Rang mischt den persistierten STATUS mit
der Disk-Existenz; nach einem Absturz kann der Status von der Realitaet abweichen.
War die kanonische Datei auf der Platte tatsaechlich vollstaendig/gut, ihr Item
aber z.B. "failed"/"queued", waehrend das Duplikat-Item ein veraltetes
"completed" ueber einer kleineren/partiellen Datei trug, wurde die gute
kanonische Datei geloescht und durch das schlechtere Duplikat ersetzt —
unwiederbringlicher Verlust der besseren Datei. Zusatzrisiko: rmSync erfolgreich,
renameSync wirft EXDEV → kanonisch weg, nichts installiert.

Fix:
- Size-Guard: Ist die kanonische Datei >= dem Duplikat, wird sie behalten und das
  (kleinere/gleich grosse) Duplikat verworfen. Eine kleinere Datei kann eine
  groessere nie ueberschreiben.
- Sichere Reihenfolge fuer den echten Austausch (kanonisch kleiner): kanonisch →
  ".dedupbak" umbenennen, dann Duplikat → kanonisch; bei Fehler (EXDEV o.ae.)
  wird die kanonische Datei aus dem Backup wiederhergestellt. Kein Loss-Fenster
  mehr. Erst nach Erfolg wird ".dedupbak" entfernt.

Test: kanonisch 1024 B (gut) + Duplikat 256 B (partiell), primaeres Item "failed"
(Duplikat rangiert hoeher) → die kanonische Datei bleibt mit 1024 B erhalten.
Ohne den Size-Guard wird sie durch die 256-B-Datei ersetzt (rot bewiesen). Volle
download-manager-Suite (168) gruen, tsc unveraendert 6.
2026-06-17 05:13:40 +02:00

8.7 KiB
Raw Blame History

Autonomer Audit-Loop — Download/Fehler/Rotation (Goal 2026-06-17, 8h)

Disziplin: erst BELEGEN (Code-Zitat + konkretes Szenario), dann adversarisch verifizieren, dann TDD-Fix. Kein Blind-Fix. Tests gruen + tsc=6 nach jeder Runde. Periodisch releasen.

Runde 1 (laeuft)

  • Discover+Verify-Workflow ueber 7 Subsysteme (scheduler-slots, unrestrict-retry, mega-rotation, classify-cooldown, mega-web-token, provider-chain-timeout, account-availability).

Meine unabhaengigen Verdachtsfaelle (Cross-Check gegen Workflow)

  1. Web-Selbst-Cooldown (Analog zum API-214-Bug, HOCH): Caller-Timeout = 60s (DEFAULT_UNRESTRICT_TIMEOUT_MS, download-manager 114) umschliesst die GANZE Kette. Mega-Web braucht legitim laenger (per-Account-Queue bis 90s + Login + Generate). Feuert die 60s nach >=8s (MEGA_DEBRID_ABORT_MIN_RUN_MS_DEFAULT=8000), setzt die Rotation aborted:debrid → 120s Account-Cooldown (debrid.ts ~2037-2048), obwohl der Account GESUND ist — die App hat aufgegeben. → Kaskade ueber Accounts. Live im jf.zip belegt: Mega-Debrid Web | TIMEOUT_COOLDOWN | reason=aborted:debrid | cooldownSec=120. Fix-Kandidat: (a) per-Provider-Timeout statt globaler 60s; und/oder (b) Caller-Timeout- Abort NICHT als Account-Cooldown werten (EMA-Demotion regelt langsame Accounts bereits), oder nur sehr kurz.
  2. Globaler 60s-Timeout kappt Failover (Advisor-bewiesen, HOCH): download-manager 8759 AbortSignal.any([cancel, timeout]) → bei Provider1-Verbrauch des Budgets abortet das Signal → debrid.ts 3805 signal.aborted → throw, kein nextProvider. Fix: per-Provider- AbortSignal.timeout, Stop nur bei USER-Cancel.
  3. Exponential-Backoff bis 120s (generic unrestrict retry) — Item sitzt bis 2 min. Pruefen ob fuer haeufige transiente Faelle zu lang.

Bestaetigte Bugs (Workflow R1: 14 confirmed / 11 refuted) — priorisiert

  • [IN ARBEIT] #1 HIGH Scheduler-Freeze: findNextQueuedItem ohne activeTasks-Guard → synchroner Admission-Loop dreht endlos wenn ein reset/overwrite-Item noch im activeTasks parkt (non-abort- observing await, z.B. Integrity-Check). Fix: if (this.activeTasks.has(itemId)) continue;. TDD-Test (Freeze-Repro mit non-abort Mock + resetItems) geschrieben.
  • #2/#3 MED mega_debrid_cooldown: Delay verworfen — kein Parser (nur debrid_link_cooldown). Fix: Parser fuer beide Praefixe, queueRetry mit echtem delayMs. (Erklaert Rapid-Retry-trotz-Cooldown im jf.zip.)
  • #7/#8 MED Mega per-Account Daily-Usage wird am Tagesgrenze NIE resettet → Accounts faelschlich "am Limit" → schrumpft MEIN neues serialized-limit. Fix: megaDebridAccountDailyUsageBytes in ensureProviderDailyUsageFresh resetten.
  • #4 MED transiente leere Web-Antwort → permanenter until-restart-Park (limitSignal vom generischen "antwort leer"). Fix: limitSignal nur vom echten Daily-Limit (NO_SERVER_RE).
  • #5 MED Web echte Bad-Credentials erreichen invalid-Branch nicht (werden ewig retried). Fix: echte Web-Login-Fehlerphrasen in invalid-Branch.
  • #6 MED onefichier/ddownload-Routing ignoriert autoProviderFallback=off. Fix: Guard in catch.
  • #14 LOW Regex-Ordering classify: quota-Branch shadowt rate_limit. Fix: rate_limit vor quota.
  • #9 LOW overwrite wipet frisch geclaimten targetPath via altem .finally.
  • #10 LOW HTTP416 shared counter mit genericErrorRetries.
  • #11 LOW fresh-retry preempt typed transient handlers.
  • #12 LOW 15-failure-shelve + shared counters → mehr Retries als retryLimit.
  • #13 LOW self-poison: queue-wait zaehlt zu elapsedMs → abort-cooldown (Analog zu meinem Web-Verdacht #1).

Refutiert / Nicht-Bug (11) — nicht anfassen

providerStartReservations dead-state; debrid_link_cooldown cleanup; supprimé-fallthrough; mega-web 180s aborts whole rotation; EMA-removed-premise; quota-no-park asymmetry; connectApi single-flight cancel-couple; per-account queue chain-break (NON-BUG); mega-web slot-hold (NON-BUG); provider abort-vs-timeout heuristic; daily-limit aggregate early-exit.

Fixes (TDD, mit Test + Release)

Batch 1 → v1.7.215 (Suite laeuft)

  • #1 HIGH Scheduler-Freeze: findNextQueuedItem activeTasks-Guard. Repro-Test (ohne Fix haengt der Event-Loop so hart, dass nicht mal vitest-Timeout feuert = Freeze empirisch bewiesen). Mit Fix 288ms.
  • #2/#3 MED parseMegaDebridCooldownRetry (export) + Handler VOR transient/generic branch → Item wartet den ECHTEN Cooldown (min ueber alle Accounts) statt 5s-Busy-Loop. 5 Parser-Tests.
  • #7/#8 MED megaDebridAccountDailyUsageBytes Reset in ensureProviderDailyUsageFresh (laeuft via getSnapshot, also auch im Stall). Test: Tagesgrenze → leer.
  • #14 LOW rate_limit-Branch VOR quota (quota matchte "limit" in "rate limit"). Test: rate_limit-Kategorie.
  • [deferred] #4 empty-response→until-restart-park: 3-consecutive-streak ist reale Mitigation gegen transiente Blips; Mega-empty-Semantik nicht sicher verifizierbar → kein Blind-Change.

Strategie-Update (LIVE-Server, Advisor-bestaetigt)

  • LOW-Fix-Schwelle HOCH: nur fixen bei NULL plausibler Regression UND einem Test der OHNE Fix rot ist. Sonst dokumentieren ("gefunden & charakterisiert" ist valides Audit-Ergebnis). Server laeuft live, auto-update, ~1 TB/h → jede unnoetige Verhaltensaenderung = Risiko.
  • Releases BUENDELN (alle 2-3 Runden / Roll-up), nicht pro Fix. Weniger Update-Churn auf dem Live-Server.
  • #5 NICHT raten: conversion.log faengt den echten Web-Login-Fehler-String schon (web-queue-Phase-Detail). Aus naechstem Bundle ernten, dann erst invalid-Phrasen ergaenzen. Kein Phrasen-Halluzinieren.
  • #13 defer: Web ist seit v1.7.214 nur noch Fallback (API-first), Selbstcooldown trifft kaum mehr; braucht workMs-Threading → groesserer Eingriff, nicht LOW-billig.
  • Vor Runde 4-5: SYNTHESE-Pass — ist Retry/Cooldown/Rotation END-TO-END kohaerent selbstheilend?

Runde 2 (Download-Ausfuehrung: stream/resume/disk/integrity/extract/persist) — Workflow whspc8ddv

14 confirmed / 7 refuted (>=2/3 adversarisch). Alle HIGH/MED unten unabhaengig am echten Code verifiziert (Zeilen zitiert) bevor gefixt. Jeder Fix mit rot-bewiesenem Test, tsc bleibt 6.

Batch 2b → noch nicht released (buendeln, dann v1.7.216)

  • #R2-1/4 HIGH Pre-alloc-stat-Reconciliation blaeht written auf Padding-Groesse auf → stille Null-Byte-Korruption auf win32. reconcileFinalizedSize() (download-completion.ts, rein+getestet), nur noch ABWAERTS-Korrektur bei preAllocated. Commit 2646cba.
  • #R2-3 HIGH Nicht-Archiv-".001" ohne Signatur wurde als extrahiert gezaehlt → ganze .00x-Familie beim Cleanup geloescht (Datenverlust). skippedNonArchives (pathSetKey) aus cleanupSources gefiltert, frisch + resume. End-to-end-Test. Commit 56bae4a.
  • #R2-9 MED + #R2-14 LOW Settings-async-Writer ohne Generations-Schutz → Lost Update; shutdown rief cancelPendingAsyncSaves nicht. Eigener syncSettingsSaveGeneration (Spiegel des Session-Pfads) + cancel in shutdown. Commit 1a33fc2.
  • #R2-6 MED Teildatei verwaist beim Entfernen eines laufenden Downloads (catch-early-return vor Cancel-Cleanup). rmSync im catch vor dem return (nach Stream-Close, kein Race). Commit 2b639b7.
  • #R2-8 MED Hash-Manifest: Pro-Zeile-Algorithmus von Dateiendung ueberschrieben → gute Datei geloescht bei fehl-etikettiertem Manifest. parseHashLine-Algorithmus uebernehmen. Commit 4578991.
  • #R2-7 MED Startup-Dedup ersetzt gute kanonische Datei durch kleineres Duplikat (+ EXDEV-Loss- Fenster). Size-Guard (kanonisch >= Duplikat → behalten) + rename-zu-.dedupbak-Reihenfolge mit Restore. Commit folgt nach voller DM-Suite.
  • [deferred/dokumentiert] #R2-5 stream-end akzeptiert truncated download (ohne Laengensignal nicht entscheidbar; Web ist post-214 nur Fallback) — nur WARN-Log sinnvoll, kein sicherer Fix.
  • [deferred/dokumentiert] #R2-10 CRC-verifizierte Kleindatei vom suspicious-small-Heuristik geloescht; #R2-11 Resume-empty-output-Bypass; #R2-12 7z-Exit-1-Warnung als Erfolg; #R2-13 Companion-.srt/.nfo- Overwrite. Je narrow/heuristisch → charakterisiert, nicht blind gefixt (LIVE-Server-Schwelle).

Batch 2 (commit, noch nicht released — buendeln mit Runde-2-Findings)

  • #6 MED onefichier/ddownload-catch respektiert autoProviderFallback=off (Guard nach abort-rethrow). Test: 1fichier KO + Fallback aus → reject, mega getLink NICHT aufgerufen (rot-ohne-Fix beweisbar). ACHTUNG-Notiz: replace_all matchte faelschlich auch den getLinkInfos-Filename-catch (~3614) → revertet (Filename-Aufloesung muss nicht-fatal bleiben). Nur die zwei Hoster-catch-Bloecke geaendert. Commit 21fb09b.
  • [deferred LOW, dokumentiert statt blind-fix] #9 overwrite targetPath-wipe, #10 HTTP416 shared counter, #11 fresh-retry preempt typed handlers, #12 shelve+shared counter, #13 queue-wait→elapsedMs, #5 Web-bad-creds. → je nur fixen wenn rot-ohne-Fix billig beweisbar + null Regression; sonst bleibt's charakterisiert.