diff --git a/main.js b/main.js index ab6cad4..7a66e92 100644 --- a/main.js +++ b/main.js @@ -1092,7 +1092,9 @@ ipcMain.handle('start-upload', (_event, payload) => { const hosters = payload && Array.isArray(payload.hosters) ? payload.hosters : []; const jobs = payload && Array.isArray(payload.jobs) ? payload.jobs : []; - debugLog(`start-upload: files=${JSON.stringify(files)}, hosters=${JSON.stringify(hosters)}, jobs=${jobs.length}`); + // At 500+ jobs JSON.stringify blew up the debug log with MB-sized lines + // per start-upload and added noticeable delay — log counts only. + debugLog(`start-upload: files=${files.length}, hosters=${hosters.length}, jobs=${jobs.length}`); const tasks = jobs.length > 0 ? buildUploadTasksFromJobs(config, jobs) diff --git a/tasks/todo.md b/tasks/todo.md index 1e87756..a0dd476 100644 --- a/tasks/todo.md +++ b/tasks/todo.md @@ -1,28 +1,32 @@ -# Account-Rotation: vollständiger Session-Lernprozess +# Perf/Stabilität Audit (nach 3.1.5) -## Problem -1. Byse "disk space full" wurde als file-rejected klassifiziert → keine Rotation. (3.1.4 ✓) -2. `pre-job-swap` checkte `_failedAccounts` VOR Semaphore-Acquire → alle parallelen Jobs probierten weiter den vollen Account. (3.1.5 ✓) -3. Wenn beim ersten Fail noch kein Fallback-Account existierte und der User DANACH einen hinzufügt → `_accountOverrides` blieb leer, keine weitere `account-failed`-Emission (nur einmalig pro Account) → System blieb stuck bis zum Neustart. (3.1.5 ✓) +Ziel: bekannte Schwachstellen aus der Review abarbeiten, jeweils mit eigenem Release. -## Fix -- [x] `lib/upload-manager.js` — Pre-Job-Swap hinter `semaphore.acquire` verschoben, plus zwei public getter: `getFailedAccountKeys()`, `getOverride(hoster)`. -- [x] `main.js` — `save-config` IPC-Handler ruft nach dem Speichern `getNextFallbackAccount` für alle failed-ohne-Override accounts im aktiven UploadManager. Findet er was, ruft er `switchAccount`. Emittiert `account-switched` an den Renderer. -- [x] Tests (4 neue): - - pre-job-swap greift für parallele Worker nach Semaphore-Queue. - - getFailedAccountKeys + getOverride als public API. - - Neustart-Reset: fresh Manager hat keine gelernte failed-Historie. - - Late-resolved Override wird von Folgejobs genutzt (mid-batch config add). -- [x] `npm test` — 80/80 grün. -- [ ] Release als 3.1.5 (auf User-OK). +## Schritt 1 — Log-Geschwätz reduzieren (main.js:1066) +- [ ] `JSON.stringify(files/hosters)` durch count-only ersetzen +- [ ] Bei 500 Jobs spart's MB-große debugLog-Einträge pro start-upload +- [ ] Release als 3.1.6 -## Behavior-Matrix -| Szenario | Verhalten | -|---|---| -| acc1 + acc2 gleich aktiv, acc1 wird voll | acc1→acc2 Rotation, alle weiteren Jobs direkt acc2 ✓ | -| Nur acc1 aktiv, acc2 mid-batch hinzugefügt BEVOR acc1 voll | Erster Fail resolved gegen frische Config, acc2 wird gezogen ✓ | -| Nur acc1 aktiv, acc1 wird voll, DANACH acc2 hinzugefügt | `save-config` trigert Late-Resolve, `switchAccount(acc2)` wird aufgerufen, Folgejobs swappen pre-job ✓ | -| App-Neustart | `_failedAccounts` in-memory → fresh, acc1 wird wieder probiert ✓ | +## Schritt 2 — persistQueueState-Write vermessen + drosseln +- [ ] Verstehen: wie groß ist das JSON bei 500 Jobs? Wie oft schreibt's während eines Batches? +- [ ] Ggf. maximale Write-Größe / Frequenz während Upload erhöhen (derzeit 10s bei uploading, 500ms sonst) +- [ ] Ggf. nur bei Status-Änderung, nicht bei Progress-Byte-Change +- [ ] Release als 3.1.7 (nur wenn echter Bottleneck gefunden) -## Review -Drei Ebenen zusammen (3.1.4 Classifier + 3.1.5 pre-swap-after-queue + 3.1.5 late-resolve) machen das Session-Lernen komplett: disk-space-voll wird erkannt, markiert, alle wartenden Jobs sehen es wenn sie dran sind, und spätere Config-Änderungen werden reaktiv aufgegriffen. +## Schritt 3 — Progress-Event-Flood drosseln (app.js:1862-1871) +- [ ] Status-Change-Events rufen sync `updateQueueActionButtons + updateStatusBar + updateStatsPanel` +- [ ] Bei 50+ parallelen Uploads → 100+ sync Callbacks/Sek +- [ ] Coalesce via rAF (wie `scheduleQueueRender` für uploading-events) +- [ ] Tests für den neuen Pfad +- [ ] Release als 3.1.8 + +## Schritt 4 — Byse-Poller-Review (lib/hosters.js:440+) +- [ ] Verstehen warum der Poller existiert (zuverlässigkeitsproblem mit direkter Response?) +- [ ] Edge-Cases prüfen: was wenn Poll 0 neue Files findet aber Upload durch war? +- [ ] Dokumentieren was funktioniert und was nicht +- [ ] Kein Release außer echter Bug gefunden + +## Offen nach diesen Schritten +- Memory-Wachstum bei langen Sessions (bräuchte Instrumentierung) +- Throughput-Skaling bei 20+ parallelen Uploads (bräuchte Lasttest) +- Netz-Ausfall-Recovery (bräuchte Netz-Interrupt-Test)