Administrator f3b1c25d8b perf(queue): halve sync work on retry of many jobs

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.

2026-04-21 16:14:58 +02:00

1.7 KiB

Raw Blame History

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

Entferne doppelten Render in retrySelectedJobs — startSelectedUpload macht das ohnehin in einem Rutsch.
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.

1.7 KiB Raw Blame History