5309f8dd69
Bewusst NUR Diagnose, KEINE Verhaltensaenderung — damit das naechste Support-Bundle das echte aktuelle Verhalten zeigt und der naechste Fix die Ursache trifft statt zu raten (live belegt: "Unrestrict Timeout nach 60s" R53/R64, API-"Token error, please log-in" kuehlt beide Accounts ab). Neues Modul conversion-trace.ts: AsyncLocalStorage-Trace, der einen unrestrict-Versuch ueber alle Schichten begleitet und EINEN strukturierten Block pro Versuch nach conversion.log schreibt (Datei-Infra wie account-rotation-log: Rotation bei 5 MB, 14 Tage Retention; im Support- Bundle). tracePhase ist no-op ohne aktiven Trace — additiv, null Risiko. Instrumentiert wird die Kern-Blindstelle der bisherigen Logs: - download-manager Boundary: runWithConversionTrace + Slot-Belegung (conv/dl/active/max) + Caller-Timeout-Attribution (was lief, als die 60s feuerten). - Provider-Kette (debrid): chain-try/ok/failed/aborted — zeigt, ob der Web->API-Failover ueberhaupt feuert oder vom globalen Abbruch gekappt wird. - Mega-Rotation: mega-account mit workMs + outcome (ok/failed/fatal/aborted) + Cooldown je Account. - API-Token-Lifecycle: token cached/pending-join/fresh-login + connectMs, getLink response_code/text — klaert die Herkunft von "Token error". - Mega-Web runExclusive: web-queue mit queueWaitMs UND workMs getrennt — klaert, ob die 60s Warten in der Queue oder echte langsame Arbeit sind. Test conversion-trace.test.ts (Formatter + ALS-Kontext-Propagation). 838/838 gruen, tsc unveraendert (6 Baseline), Build ok.
38 lines
3.1 KiB
Markdown
38 lines
3.1 KiB
Markdown
# Massives Conversion-Logging (v1.7.213) + Failover-Fix
|
|
|
|
## Problem (live belegt, 2026-06-17)
|
|
- Links haengen mit "Unrestrict Timeout nach 60s", R53/R64, halten Download-Slot → Stop-and-Go.
|
|
- Web-first: 1 globaler 60s-Timeout um die GANZE Provider-Kette → Web frisst das Budget,
|
|
API-Failover wird NIE versucht (debrid.ts 3801 `signal.aborted` → throw). Retry startet wieder bei Web.
|
|
- API-first laeuft "um einiges fluessiger" (User bestaetigt: API resolved UND downloaded auf dem Server).
|
|
- ABER: API-Token-Fehler ("Token error, please log-in") + "Login oder Unrestrict fehlgeschlagen"
|
|
→ beide Accounts kriegen Cooldown → Doom-Loop. connectApi single-flightet Logins schon (pendingConnects),
|
|
also ist die Token-Ursache NICHT trivial → braucht Token-Lifecycle-Logging.
|
|
|
|
## Kern-Blindstelle
|
|
Bestehende Logs (account-rotation.log) zeigen `elapsedMs` aber NICHT:
|
|
- queue-wait vs aktive Arbeit (war der 60s-Timeout Warten in der Queue oder echtes Arbeiten?)
|
|
- Token-Lifecycle (cacheHit/freshLogin/invalidation) → woher "Token error"?
|
|
- Provider-Ketten-Entscheidung pro Item (welche Provider, welches Budget, warum Stopp)
|
|
- Was war in-flight als der Caller-60s-Timeout feuerte (Provider/Account/Phase) + Slot-Belegung
|
|
|
|
## Plan (Release 213 = NUR Logging, bewusst KEINE Verhaltensaenderung — damit das naechste Bundle das ECHTE aktuelle Verhalten zeigt)
|
|
- [x] `src/main/conversion-trace.ts`: AsyncLocalStorage-Trace + dedizierte `conversion.log`. EIN strukturierter Block pro Unrestrict-Versuch.
|
|
- [x] Wiring: init in app-controller, shutdown, support-bundle.
|
|
- [x] Instrumentiert (nur tracePhase-Calls, additiv, no-op ohne aktiven Trace):
|
|
- download-manager unrestrict-Boundary: runWithConversionTrace + Caller-Timeout-Attribution + describeSlotOccupancy.
|
|
- debrid.ts Provider-Kette: chain-try/chain-ok/chain-failed/chain-aborted (zeigt ob Failover feuert).
|
|
- debrid.ts Mega-Rotation: mega-account workMs + outcome (ok/failed/fatal/aborted) + cooldown.
|
|
- MegaDebridClient connectApi/doConnectApi/unrestrictViaApi: token cached/pending-join/fresh-login + connectMs + getLink response_code/text (DAS klaert "Token error").
|
|
- mega-web-fallback runExclusive: web-queue queueWaitMs + workMs (DAS klaert ob 60s = Warten oder Arbeit).
|
|
- [x] Test: conversion-trace.test.ts (Formatter + ALS-Kontext). tsc unveraendert 6.
|
|
- [ ] Build + Suite gruen. Release 213 (Gitea + Mirror).
|
|
|
|
## DEFERRED auf 214 (erst NACH Logs, kein Blind-Fix mehr)
|
|
- 60s global → per-Provider-Budget (Failover feuert) — proven, aber erst messen: tritt der 60s ueberhaupt bei API-first auf, und ist es Queue oder Arbeit?
|
|
- API Token-Error Doom-Loop ("Token error, please log-in") — Mechanismus per conversion.log verifizieren, DANN fixen (evtl. per-Account-Serialisierung fuer API wie bei Web).
|
|
- Config-Realitaet an User: 2. Account (xe) lief abgelaufen/deaktiviert → 212-Parallelitaet griff nicht; API-first ist der schnelle Pfad.
|
|
|
|
## Review
|
|
Logging-Release: pure Diagnose, null Verhaltensrisiko. Naechster Schritt: User reproduziert, schickt Bundle, conversion.log zeigt Queue-vs-Arbeit + Token-Lifecycle eindeutig → praeziser Fix in 214.
|