8df6de06f1
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Administrator
|
0a607adb29 |
fix(queue): stop finished uploads from re-appearing as pending ghosts across restart
The completed-upload dedup guard (_completedUploadKeys, "file|hoster") is the single source of truth that keeps a finished job from being re-materialised as a "Bereit" preview by buildQueuePreview(). Three independent paths leaked ghosts back into the queue: A) removeJobFromIndex() unconditionally DELETED the dedup key. The removeFromQueueOnDone auto-remove path (handleProgress), the batch-done sweep, and the terminal-job prune all call removeJobFromIndex on a *finished* job, so the guard handleProgress had just added was immediately wiped and buildQueuePreview re-created the job as a preview both mid-session and after restart. removeJobFromIndex now takes keepCompletedKey; the three auto-removal call sites pass true (keep the guard), while the manual-delete sites keep the old behaviour (drop the guard so the user can re-add the file). D/E) The dedup guard lived only in memory, so every restart began with an empty set and buildQueuePreview rebuilt ghosts from the persisted selectedFiles. buildPersistedQueueState() now serialises the keys whose file is still in the snapshot (completedKeys) and restoreQueueStateFromConfig() re-seeds them. To keep deliberate re-uploads working, applyHosterSelection() clears the persisted key for every freshly (re-)added file: re-adding through the hoster modal is the explicit "upload this again" signal. Both retry paths (retrySelectedJobs, _retryFailedFromBuckets) mutate the existing job in place instead of relying on buildQueuePreview, so they are unaffected. H) buildQueuePreview() excluded error jobs from its existingKeys set, so a file+hoster that already had an 'error' row got a second 'preview' row stacked beside it. Error jobs now count as existing. B/C) parseUploadLogLine() took the filename from a fixed field index and trimmed it. A pipe inside the link shifted the field (entry lost from the log-based dedup) and trimming broke matching against the untrimmed OS basename used as the queue-job key. The filename is now the last non-empty field and is no longer trimmed, so log lines with pipes in the URL and leading-space filenames both match end-to-end. 362 tests pass, lint clean on all touched files. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Administrator
|
eeec1d150c |
fix(queue): completed files no longer reappear in the queue after restart
Closing the app (especially during an active upload or on a hard kill) and reopening sometimes left already-uploaded files sitting in the queue as if still pending. Root cause is three layers stacked: 1. Persist-starvation: persistQueueStateSoon() reset a 10s debounce on every progress event, so during an upload the on-disk queue snapshot was never rewritten and stayed frozen at the pre-upload state (all jobs "preview"). 2. The beforeunload sync flush only covers a clean close; a hard kill / crash leaves that stale snapshot on disk. 3. Startup auto-dedup only dropped jobs with status "done". The completed files were stored as "preview" in the stale snapshot, so they survived and reappeared. Fix (mechanism-independent — holds whether the stale snapshot came from starvation, a mid-upload close race, or a hard kill): FIX A (core, durable): the upload log is the source of truth. Each persisted snapshot is now stamped with savedAt; on restart any restored job whose newest matching log entry is timestamped at/after floor(savedAt) is dropped regardless of status — it provably completed after the snapshot, so a "preview" row for it is a ghost. lib/queue-dedup.js gains an additive 3rd savedAt param; without savedAt or without log timestamps it behaves exactly as before (the 5 canary tests stay green, so intentional re-uploads of older files still survive). FIX B: new lib/throttle-timer.js with a max-wait. During uploads the snapshot is now written at most ~20s into a continuous progress burst instead of never; idle stays a pure debounce. The fallback shim honors max-wait too, so a missing library can never silently reintroduce the starvation. FIX C: the synchronous close-write retries renameSync on EBUSY/EPERM/EACCES and uses a pid-unique tmp (de-conflicts it from config-store._atomicWrite's fixed .tmp). A startup sweep reclaims orphaned <config>.<pid>.tmp files left by a hard kill between write and rename. lib/upload-log.js extracts formatUploadLogLine + parseUploadLogLine from main.js so the real writer -> reader -> gate seam is unit-tested (a future log-format or epoch-basis change can no longer pass green while breaking the fix). Verified: 334/334 tests green (incl. throttle fake-clock starvation/maxWait, ts-gate multi-hoster partial-completion, and the real-format seam tests), ESLint clean, smoke-boot identical to baseline, and an adversarial multi-agent review (15 findings, 14 refuted, 1 low — the tmp orphan, now swept) on the diff. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |