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.
1.1 KiB
Lessons
2026-04-21 — DOM-Doppelrender bei Bulk-State-Changes
Symptom: User klickt auf "Erneut versuchen" mit 500+ Jobs → App hängt sekundenlang.
Root cause: retrySelectedJobs() ruft renderQueueTable + updateQueueActionButtons + updateStatusBar auf, startSelectedUpload() ruft direkt danach genau dieselben Funktionen nochmal auf.
Regel: Wenn ein Click-Handler await anotherHandler() aufruft und der innere Handler seinen eigenen kompletten Render-Zyklus hat, NIEMALS noch einen davor. Einmal ist genug — der folgende innere Render sieht die frischen State-Mutationen ohnehin.
Wie anwenden: Vor jeder await fn()-Folge in einem Handler prüfen: macht fn schon renderQueueTable()? Wenn ja, äußere Render-Calls löschen.
2026-04-21 — Keine fake Build-ETAs
Symptom: User wartet 5+ min auf Tauri-Build den ich mit "1-2min" angekündigt habe.
Regel: Tauri-Release-Builds brauchen real 3-6 min (Rust + NSIS + MSI). Keine Zeitangabe oder ehrlich "kann 3-6min dauern" schreiben.
Wie anwenden: Wenn User nach Status fragt: sofort tail des Logs + ls des Bundle-Ordners zitieren, nicht raten.