Summary
When a user's session expires while bulk-download zips are being prepared, the zips are built server-side but never offered to anyone: their bulk_download_complete events fire into the socket of the session that is being torn down, and after re-authentication nothing replays them. The client currently detects the situation and shows a finite "downloads interrupted, please re-run" toast (see the expiry handling in bulkDownloadQueryFn, invokeai/frontend/web/src/services/api/endpoints/images.ts), which is honest but still loses the work.
Proposed fix
Persist scheduled bulk-download jobs per account (item name + requesting user), and on (re-)authentication replay pending completions to the user's fresh socket — at which point the "preparing"/"ready" toast flow can resume instead of asking the user to re-run the download. This also covers the narrower window where a zip completes between socket teardown and reconnect.
Context
Raised by @JPPhoto in review of #9394 ("Consider persisting download jobs by account and replaying them after re-authentication; this eliminates expiry-induced zip loss and stuck preparation toasts"). #9394 bounds the client-side damage (correct toasts, no permanent "preparing" banner, no payload leaking across sessions); this issue tracks the recovery half.
Summary
When a user's session expires while bulk-download zips are being prepared, the zips are built server-side but never offered to anyone: their
bulk_download_completeevents fire into the socket of the session that is being torn down, and after re-authentication nothing replays them. The client currently detects the situation and shows a finite "downloads interrupted, please re-run" toast (see the expiry handling inbulkDownloadQueryFn,invokeai/frontend/web/src/services/api/endpoints/images.ts), which is honest but still loses the work.Proposed fix
Persist scheduled bulk-download jobs per account (item name + requesting user), and on (re-)authentication replay pending completions to the user's fresh socket — at which point the "preparing"/"ready" toast flow can resume instead of asking the user to re-run the download. This also covers the narrower window where a zip completes between socket teardown and reconnect.
Context
Raised by @JPPhoto in review of #9394 ("Consider persisting download jobs by account and replaying them after re-authentication; this eliminates expiry-induced zip loss and stuck preparation toasts"). #9394 bounds the client-side damage (correct toasts, no permanent "preparing" banner, no payload leaking across sessions); this issue tracks the recovery half.