Photo upload queues: retries and account changes

Selection does not mean upload completion

usePhotoUpload keeps selected photos in one queue, with waiting, uploading, done and failed states. Failed items remain visible so users can identify them and choose to retry or remove them.

The changed callback returns server media records only for done items. pending remains true for any non-done item, including failed ones. The interface needs to explain why submission can remain unavailable even when no upload is actively running.

select → waiting → uploading → done
                        ↓
                      failed → retry → waiting

submit-ready media = items with status === done
unresolved selection = any item with status !== done

The tradeoff of a serial queue

The current implementation awaits uploads one at a time. This simplifies state changes and retention of failed items, but large selections can take longer on slow networks. Bounded concurrency should be considered after measuring sizes, failure rates and waiting times.

remove and retry are disabled while the queue is running. Files beyond the selection limit have their preview resources released. Failed items still count toward that limit until removed.

Old callbacks lose ownership when identity changes

run captures generation at startup. An identity change calls reset, increments generation, releases previews and clears the list. A returning callback checks that generation before updating state. Unmount also invalidates the current generation.

// Simplified ownership guard; not the complete queue
const version = generation;
const media = await upload(file);
if (version !== generation) return;
item.media = media;
item.status = 'done';

Ignoring a callback does not cancel the upload. The request and server write may already have completed. Orphan-media cleanup needs a server policy; generation is neither server authorization nor rollback.

Previews have a lifecycle too

The shared logic delegates preview cleanup to a release callback. Removal, reset, unmount and rejected selections all trigger cleanup. Web object URLs created with URL.createObjectURL should be revoked when no longer used; mini-program temporary paths follow their platform rules.

The five public logic checks cover selection limits, retry, ready-list updates after removal, identity changes and callbacks after unmount. They use a Vue stub and controlled promises, not real transfer speed, album permissions or long-running memory measurements.

What to verify next

• Repeatedly select and remove photos on real devices while observing preview-resource usage.
• Switch accounts during upload, then inspect media ownership and cleanup of unreferenced files on the server.
• If concurrency is added, test a new queue after reset so an old finally block cannot overwrite its running state.