f3b1c25d8b
retrySelectedJobs() was calling renderQueueTable + updateQueueActionButtons + updateStatusBar and then immediately awaiting startSelectedUpload(), which runs the exact same trio right after. At 500+ failed jobs the double render/sort/button-refresh freezes the UI for several seconds after clicking "Erneut versuchen". Drop the outer render trio — startSelectedUpload's one is enough. The inner call sees the freshly-mutated job state in the same tick, so the visible result is identical with half the work.
23 lines
1.7 KiB
Markdown
23 lines
1.7 KiB
Markdown
# Retry-Hang bei 500-600 failed jobs
|
|
|
|
## Problem
|
|
User hat 500-600 Uploads, davon viele `error`. Markiert alle, klickt "Erneut versuchen" → App friert mehrere Sekunden ein.
|
|
|
|
## Root Cause (renderer/app.js)
|
|
`retrySelectedJobs()` (Z.1952) → mutiert 500 Jobs → `renderQueueTable() + updateQueueActionButtons() + updateStatusBar()` (Z.1988-1990) → dann `await startSelectedUpload()` (Z.1992) → das mutiert SIE ERNEUT (Z.1724-1732) → rendert NOCHMAL (Z.1733-1735).
|
|
|
|
**Doppelter DOM-Zyklus + doppelte Mutation bei 500 Jobs = hängt-Gefühl.**
|
|
|
|
Zusätzlicher Multiplikator: main.js:1066 `JSON.stringify(files)` in `debugLog` — auch wenn `files` leer ist. Außerdem `buildUploadTasksFromJobs` loopt synchron 500x im main-Thread.
|
|
|
|
## Plan
|
|
- [x] Entferne doppelten Render in `retrySelectedJobs` — `startSelectedUpload` macht das ohnehin in einem Rutsch.
|
|
- [x] Lesson dokumentieren in `tasks/lessons.md`.
|
|
- [ ] (optional, später) main.js:1066 — debugLog nicht mit JSON.stringify(files/hosters), nur counts loggen.
|
|
- [ ] (optional, später) Progress-Event-Flood während laufendem Upload: batch via rAF statt sync updateQueueActionButtons+updateStatusBar+updateStatsPanel.
|
|
|
|
## Review
|
|
Fix entfernt eine komplette Render-Pass-Runde vor dem Aufruf von `startSelectedUpload`. Bei 500+ Jobs halbiert das die Sync-Work im Click-Handler (Sort, Virtual-Render, Button-Update, StatusBar-Update). `selectedJobIds` bleibt korrekt befüllt weil die Selektion VOR `startSelectedUpload` gesetzt wird. `persistQueueStateSoon` ist debounced, deshalb kein Zusammenspielproblem.
|
|
|
|
Funktional identisch: Die Jobs durchlaufen am Ende dieselbe State-Kaskade (reset → queued → getting-server → uploading), nur mit einem statt zwei Render-Zyklen dazwischen.
|