feat: Video generation

[lstein]

Summary

This PR adds basic support for AI-based video generation using the Wan 2.2 family of text-to-video and image-to-video models. Currently it can only be used through the workflow editor.

invoke-videos.mp4

This PR adds the following support:

• A new Video type, with support for upload, thumbnail generation, and metadata storage.
• New movie player functionality in the viewer.
• A Wan Denoise Video node for denoising Wan 5D tensors into latents
• A Latents To Video node for decoding the denoiser latents
• A few image nodes for selecting frames from videos and concatenating videos together
• Template workflows that show typical text-to-video and image-to-video graphs.

Important notes

• This PR now incorporates the full Wan 2.2 image-generation stack that previously lived in Wan 2.2 stack: txt2img, img2img, inpaint, outpaint, LoRA support #9158 (which it supersedes), so it can be merged on its own.
• It triggers a database migration, so run this in a test root.

Testing plan

• Smoke-test T2V Lightning (832×480, 81 frames, 4 steps, CFG 1.0)
• Smoke-test I2V Lightning with a 16:9 source image
• Verify auto-switch to new video on completion, full-resolution first-frame preview, inline playback
• Upload an MP4 from disk; verify it appears in the gallery and plays
• Drag a gallery video onto a Video Primitive; verify the field populates
• Exercise the video concatenate node by joining two videos using the various transition options
• Run on Windows / macOS to confirm the imageio FFmpeg path works on those platforms

Getting Started Hints

Run uv pip install to pick up the new dependency on the ffmpeg library, and of course rebuild the front end.

Install the following from the starter model collection:

• Wan 2.2 TI2V-5B (Q4_K_M) -- a very small, low-quality video generator suitable for 12 GB VRAM or less

• Wan 2.2 T2V A14B High Noise (Q4_K_M) - text-to-video transformer, rough phase

• Wan 2.2 T2V A14B Low Noise (Q4_K_M) - text-to-video transformer, refiner phase

• Wan 2.2 T2V Lightning High Noise (4-step, V1.1) - turbo LoRA, rough phase

• Wan 2.2 T2V Lightning Low Noise (4-step, V1.1) - turbo LoRA, refiner phase

The corresponding models for image-to-video are:

• Wan 2.2 I2V A14B High Noise (Q4_K_M)
• Wan 2.2 I2V A14B Low Noise (Q4_K_M)
• Wan 2.2 I2V Lightning High Noise (4-step, V1.1)
• Wan 2.2 I2V Lightning Low Noise (4-step, V1.1)

The encoder and VAE should download as dependencies.

Give it a spin! There are several working templates in the Workflow library that you can start with:

• Text to Video - Wan 2.2 -- basic text to video. Select the TI2V-5B model if you are low on VRAM and leave "Transformer (Low Noise) empty. If you have >=16 GB, you can use the high-quality A14B models, apply the high noise transformer model to the Main Model "Transformer" field, and the low noise transformer model to the "Transformer (Low Noise)" field. Select the models you downloaded for the standalone VAE and T5 Encoder fields. Type in a prompt, and use the default values for CFG, image dimensions, frames and steps.
• Text to Video - Wan 2.2 Lightning -- This is the same as above, but has loaders for the high and low noise lightning LoRAs which will reduce the number of required steps to 4.
• Image to Video - Wan 2.2 -- basic reference image to video. You need to provide a reference image and a prompt describing what to do with it. The reference image will be the first frame of the image. The image should have the same aspect ratio as the desired video, but doesn't need to be exactly the same dimensions.
• Image to Video - Wan 2.2 Lightning -- as above, but with nodes for the two lightning LoRAs for dramatic speedups.

The models work best across a limited series of dimensions. The ones I've tested are:

• 720 x 480
• 480 x 720
• 832 x 480
• 480 x 832

On my RTX 5060Ti it takes 3-4 minutes to generate a video when using the two Lightning LoRAs.

If you have lots of VRAM you can try increasing the frame count, but these videos get big fast. Alternatively, you can create a workflow that captures the last frame of the original video, generates a new video on top of it, and concatenates the two together. I've got a workflow that works well for this, but haven't added it to the branch yet.

🤖 Generated with help from Claude Code

[JPPhoto]

@lstein I have to take a break at this point. Here's what I did:

Fixed

• I added cross-tab media-cookie locking when Web Locks are unavailable.
• I added an absolute upload deadline so drip-feed requests cannot retain upload slots indefinitely.
• I added cross-platform RSS monitoring for decoder workers and their FFmpeg descendants.
• I made partial board deletion failures explicit for both images and videos, including frontend warnings and cache invalidation.
• I made combined uncategorized deletion report rejected image or video requests and partial item failures.

Still Open, Non-Merge Blockers

• invokeai/app/util/video_thumbnails.py: an unexpected proc.communicate() exception can leave the decoder worker and descendants running. This needs an injected OSError test and unconditional process-tree cleanup.
• invokeai/frontend/web/src/app/store/enhancers/reduxRemember/driver.ts: direct client-state persistence requests ignore refreshed-token headers, so persistence-only sessions can expire while active.
• invokeai/app/api/routers/videos.py: star and unstar operations silently omit authorization or storage failures instead of reporting partial failure.
• invokeai/app/api/routers/videos.py: duplicate names in batch deletion can be processed repeatedly and potentially appear in both successful and failed result lists.
• invokeai/app/api/routers/videos.py: delete, star, and unstar request lists lack item-count and string-length bounds.
• invokeai/app/api/routers/gallery.py and invokeai/app/api/routers/videos.py: pagination parameters lack lower and upper bounds, including protection against unbounded SQLite limits.
• invokeai/app/api/routers/videos.py: upload validation verifies server decoding but does not guarantee browser codec compatibility.
• invokeai/app/api/routers/videos.py: deletion racing with range-serving stat/open operations can still produce an uncontrolled FileNotFoundError.
• invokeai/app/api/routers/videos.py: accepted uploads still require both multipart spool storage and a route-level temporary copy, so concurrent near-limit uploads can consume substantial temporary disk space.
• invokeai/app/services/boards/boards_default.py: board listing still adds per-board video cover and count queries to the existing N+1 query pattern.
• docs/src/content/docs/features/gallery.mdx: partial board deletion behavior and preserved uncategorized media still need documentation.

Can you do a review and determining what still needs to be fixed here vs. in a follow-on PR?

[lstein]

Self-review of the post-30f8e250d6 commits (e38c243f4e…d8da20f826)

I ran a deep multi-agent review over the four commits pushed since the last review round (media resilience, auth refresh hardening, and workflow-gap fixes). Every finding below was independently verified against the code. Fixes are in progress and will be pushed to this branch.

Confirmed issues

1. DeleteVideoModal: confirming a delete rejects the promise as "User canceled" — DeleteVideoModal.tsx binds onClose={api.cancel}, but ConfirmationAlertDialog's accept handler calls acceptCallback() then onClose() synchronously. confirmDeletion suspends at await handleDeletions, then cancelDeletion rejects the still-pending promise before the deletion settles, so callers (useGlobalHotkeys, CurrentVideoPreview) treat every successful deletion as a cancel. DeleteImageModal uses api.close — the video modal deviates from the working pattern.

2. 1 GiB decode-worker memory caps kill videos the code explicitly allows — MAX_FRAME_PIXELS permits 64 MP frames (192 MiB RGB). The worker transiently holds ~3–4 frame-sized copies (ascontiguousarray, np.save BytesIO, getvalue()), so a legal near-cap video exceeds both the worker-side RLIMIT_AS headroom (video_decode_worker.py) and the parent-side 1 GiB RSS kill (video_thumbnails.py, which also sums the ffmpeg child's RSS). Uploads 415, thumbnails/concat fail, and the discarded _memory_exceeded event means it surfaces as a generic decode error.

3. Media-cookie fetch holds the exclusive cross-tab lock with no timeout — services/api/index.ts fetches /auth/media-cookie with no AbortSignal inside runWithMediaAuthLock; login/logout serialize through the same lock. One stalled POST blocks logout in every tab indefinitely. And since the middleware mints X-Refreshed-Token on every successful mutation (no near-expiry check), bulk operations pay one serialized extra round trip per request.

4. Refreshed tokens silently dropped when the media-cookie POST fails — the token commit is gated on mediaCookieResponse.ok with no retry and no fallback; the server no longer sets the cookie itself. Behind a proxy that mishandles that one route (or a persistent 5xx), every refreshed token is discarded and an active user hard-expires mid-work.

5. Logout paths other than UserMenu never pause the media-cookie refresh — only UserMenu wires pauseMediaCookieRefreshForLogout. sessionExpiredLogout (ProtectedRoute ×2, api/index.ts) doesn't pause, the hook lives in GlobalHookIsolator outside ProtectedRoute so it never unmounts, and the effect cleanup cancels timers but never aborts in-flight fetches — a pending refresh re-mints the HttpOnly cookie after logout (constructible via the cross-tab logout path where the JWT is still valid).

6. Pause during the final retry permanently kills cookie self-heal — if pause() aborts attempt 2, the catch hits RETRY_DELAYS_MS[2] === undefined and returns with nextAttemptIndex still null, so resume() no-ops. After a failed server logout the user stays logged in with no cookie and no refresh path until a full reload. Each pause/resume also burns a retry slot.

7. Upload decode-probe timeout → 415 for valid MP4s — extract_video_frame returns None on the 30 s subprocess timeout as well as genuine undecodability, and the router maps both to 415 "Failed to read video". A loaded server rejects valid uploads. The upload path also now spawns three decode workers per upload (probe, decodability check, thumbnail) — the probe-time frame is never reused.

8. Concat hard-errors when one clip's probed fps is unknown — removing the first_fps or 16.0 fallback means one fps=None probe (which probe_video produces by design for metadata-poor containers) mixed with known rates raises, even when all known rates agree. Previously-working workflows now fail mid-execution. (The disagreeing-known-rates error is a legitimate fix; the mixed-unknown case is the regression.)

9. Benign play() AbortError now raises an error toast — handleVideoError toasts unconditionally (no AbortError filter, no media-cookie-refresh guard). Play-then-immediately-close/navigate, or a restored session's 401 before self-heal completes, shows a spurious "Unable to Play Video" toast; the old code silently rolled back isPlaying.

10. Ownership skips and 404 races reported as failed video deletes — delete_videos_from_list/delete_uncategorized_videos add HTTPException names to failed_videos (contradicting the "skip videos not owned" comment), so multiuser shared-board deletes and two-tab races toast "N videos could not be deleted". The image endpoints silently skip HTTPException, so mixed selections report inconsistently.

Additional confirmed items (lower severity)

• The localStorage fallback lock's waiter lease expires after 30 s of queueing (waiters never renew their ticket; heartbeat starts only after acquisition) — mutual exclusion violated, though only on browsers without navigator.locks.
• delete_board's failed_images/failed_videos set-diff races with concurrent moves (spurious failure reports) and duplicates the full-board queries the services already run — the services should return (deleted, failed).
• delete_images_from_list still swallows failures (except Exception: pass) so failed_images is always empty — asymmetric with the video path.
• SlidingWindowTokenMiddleware now does a synchronous SQLite user lookup on the event loop for every mutating request.
• Cleanup: the low-noise-CFG block is copy-pasted between wan_denoise.py and wan_video_denoise.py (and >= 1.0 and != 1.0 is just > 1.0); the summary-toast block is duplicated in DeleteBoardModal; several new tests assert on readFileSync source text rather than behavior.

🤖 Generated with Claude Code

[lstein]

Fixes for the self-review round — pushed as 5c5f495c78 + e224f81deb

All 14 confirmed items from the self-review above are fixed in 5c5f495c78:

Frontend

1. DeleteVideoModal accepted-delete rejection — confirmDeletion now detaches the promise callbacks before the async deletion, so the accept path's synchronous onClose (still api.cancel, preserving the dismissal contract) is a no-op after confirm. Behavioral tests cover both confirm-then-cancel and plain dismissal.
2. Media-cookie sync holds the cross-tab lock unbounded — the fetch now carries AbortSignal.timeout(10s), and acceptance is throttled to once per minute so bulk mutations stop paying a serialized round trip each.
3. Refreshed tokens dropped on cookie-sync failure — the token commit is no longer gated on the cookie POST succeeding; only an explicit 401/403 (server rejecting the token itself) blocks it. A 5xx/network failure keeps the session sliding and lets the cookie self-heal.
4. Logout paths that never paused the refresh — the hook's effect cleanup (which runs on every isAuthenticated flip, covering sessionExpiredLogout and direct logout) now aborts in-flight refreshes so a pending response can't re-mint the cookie post-logout. UserMenu's pause-and-await flow is unchanged.
5. Pause during the final retry killed self-heal — a paused abort now resumes the same attempt instead of consuming a slot (and no longer strands nextAttemptIndex at null).
6. Spurious "Unable to Play Video" toasts — AbortError from play() rolls back silently; load errors during the pending media-cookie self-heal window are suppressed (the URL bump reloads the element once the cookie lands).
7. Fallback-lock waiter lease expiry — waiters renew their ticket while queueing, so a >30 s wait can no longer violate mutual exclusion.

Backend
8. 1 GiB decode memory caps killed legal videos — worker RLIMIT_AS headroom raised to 4 GiB and the parent RSS kill to 3 GiB, both derived from the 64 MP MAX_FRAME_PIXELS math and cross-referenced; monitor poll coarsened to 250 ms.
9. Upload probe timeout → false 415 — a decode-worker timeout now raises VideoDecodeTimeoutError and is treated as inconclusive (upload proceeds; save-time thumbnailing is the backstop). The probe's decoded frame is reused as the thumbnail source via an optional first_frame param, dropping one worker subprocess per upload.
10. Board-delete failure reporting raced — delete_images_on_board/delete_videos_on_board now return (deleted, failed) and delete_board reports the services' ground truth, removing the router-side listing diff (and its two duplicate full-board queries).
11. Auth skips reported as failed video deletes — the video list/uncategorized endpoints skip HTTPException silently, matching images; conversely delete_images_from_list now populates failed_images for genuine failures, matching videos.
12. Concat hard-error on unknown fps — an unknown probed rate mixed with agreeing known rates uses the known rate again; disagreeing known rates still require an explicit Output FPS.
13. Middleware sync SQLite on the event loop — the sliding-window user lookup runs via run_in_threadpool.

e224f81deb separately deflakes test_drip_feed_upload_cannot_hold_capacity_past_absolute_timeout on py3.12 windows-cpu: the test's 20 ms absolute deadline raced Windows' ~15.6 ms timer granularity, so the deadline could fire before the first chunk was delivered (assert 1 > 1). The margins are widened (250 ms deadline / 1 s idle) so the drip-feed scenario actually occurs on coarse timers.

Backend suite: 1833 passed. Frontend suite: 1475 passed. eslint/prettier/tsc/ruff clean.

🤖 Generated with Claude Code

[lstein]

@JPPhoto Thanks for the thorough pass — and for the fixes you landed directly. I verified all 11 of your "Still Open, Non-Merge Blockers" against the current head and triaged them by a simple rule: items that are small, self-contained, and scoped to surfaces this PR introduced are fixed here; anything needing schema changes across images+videos, protocol changes, policy decisions, or larger refactors moves to a follow-on PR so this one can converge.

Fixed in this PR (751231941b)

1. _run_worker process-tree leak — confirmed: the generic except Exception path didn't terminate the tree, and the finally stopped the RSS-monitor backstop, so an OSError from communicate() would orphan the worker + ffmpeg forever. Now terminates unconditionally, with the injected-OSError test you asked for (plus a spawn-failure case).
2. driver.ts ignores refreshed tokens — confirmed and nastier than it looks: persistence POSTs do mint X-Refreshed-Token (and GETs deliberately don't), so a session whose only traffic is client-state persistence never slides and hard-expires mid-activity. The acceptance flow is extracted from dynamicBaseQuery into a shared acceptRefreshedToken (same cross-tab lock, cookie sync, throttle, and auth-generation guards) and the driver now commits through it.
3. Duplicate names in batch deletion — confirmed for admins (incl. single-user mode): the second pass's not-found is a plain Exception, so the name landed in both deleted_videos and failed_videos → spurious partial-failure toast. Both video and image list-delete endpoints now dedup; regression test added.
4. Pagination bounds — confirmed, and the sharpest of the batch: limit flows verbatim into SQL and a negative LIMIT means unlimited in SQLite, so GET /gallery?limit=-1 materialized the entire gallery in one request. Both endpoints this PR introduced (gallery items, video list) now clamp offset ge=0, limit ge=0 le=1000 (ge=0 because the frontend uses limit: 0 for count-only queries). openapi.json regenerated; schema.ts is unchanged since the constraints don't alter the generated types. Bounding the pre-existing images endpoint is deferred to the follow-on to keep this PR's schema surface to what it introduced.
5. Delete vs. range-serve race — confirmed: exists()/stat()/open() and FileResponse's lazy open all raced stage_delete's atomic rename → 500. get_video_full now opens the file once and serves HEAD/range/full from that fd (full downloads stream chunked from the handle — trades sendfile for race immunity, same zero-RAM property). The thumbnail endpoint already had the equivalent hardening.
6. Double temp storage (mitigation) — the multipart spool is now closed immediately after the body copy, shrinking the ~2 × 1 GiB × 4-concurrent worst case to the copy loop itself. The true single-copy fix (streaming multipart consumer) is follow-on material — and note the spool path can't simply be reused: a rolled-over SpooledTemporaryFile is an unlinked anonymous file with no path to hand to ffmpeg.
7. gallery.mdx — documented the shared-board deletion semantics (non-admins permanently delete only their own media; others' items move to Uncategorized) and the kept-on-file-delete-failure → Uncategorized behavior with its UI warning.

Deferred to a follow-on PR (with reasons)

• Star/unstar partial-failure reporting — real, but images have the identical storage-failure silence and no failed_* field either; fixing videos alone re-opens the parity argument. Wants one consistent images+videos change with a single OpenAPI regen. (One nuance: images star re-raises auth failures mid-batch while videos skip them — I'd argue videos' behavior is the keeper.)
• Batch list bounds (max_length) — same story: 6 endpoints across images+videos, schema change, one regen. Will do together with the star/unstar change.
• Browser codec compatibility — needs the decode worker's probe protocol extended to surface codec_name, plus a policy call on HEVC (browser-dependent). Deserves its own focused change.
• Board listing N+1 — confirmed: this branch adds 2 per-board queries (video cover + count) on top of the pre-existing 3, so 50 boards = 250 queries. The right fix is batched GROUP BY counts + window-function covers across four record services (~5 queries total per listing) — a perf refactor I don't want to review-load onto this PR.
• Upload single-copy streaming — the real fix for the temp-disk item, per above.

Happy to reshuffle any of these if you disagree with the split.

🤖 Generated with Claude Code

[JPPhoto]

I am going to work on these, possibly some from the follow-up as it's getting large, too:

Merge Blockers

• invokeai/app/api/routers/videos.py:367: The delete, star, and unstar endpoints accept unbounded list[str] request bodies with unbounded item lengths. Star and unstar also process duplicate names repeatedly. Because each item triggers synchronous authorization and database operations, an authenticated tenant can submit arbitrarily large batches and monopolize API and database resources. Test: Verify the maximum allowed batch succeeds, a batch one item over the limit and an overlong name return 422 before any service call, and duplicate names cause only one mutation per video.
• invokeai/app/api/routers/videos.py:51 and invokeai/app/util/video_thumbnails.py:41: The upload controls bound individual requests and workers but not their combined resource consumption. Four uploads can transiently consume about 8 GB of temporary storage while four decoder trees are independently permitted up to 3 GB RSS each; one tenant can consume about 4 GB of temporary storage and 6 GB of decoder RSS. This can exhaust disk, tmpfs, or RAM on supported 8 GB and 16 GB systems despite the per-user slot limit. Test: Run two uploads for one user and four across users with workers held below the per-worker threshold, and assert an aggregate disk and memory budget rejects or queues excess work while a normal upload still completes. Document the resulting operator limits under docs/src/content/docs/start-here/system-requirements.mdx.

Follow-up PR

• invokeai/app/api/routers/videos.py:661: get_video_thumbnail() checks Path.is_file() but returns a lazy FileResponse. A concurrent delete can rename the thumbnail after the check and before Starlette opens it, producing the same uncontrolled server error that get_video_full() was changed to avoid. Test: Obtain the route response, stage-delete the thumbnail before invoking the ASGI response, and assert either a controlled 404 or successful descriptor-backed response instead of RuntimeError or 500.
• invokeai/app/api/routers/videos.py:771: Star and unstar swallow every non-HTTP exception, while StarredVideosResult and UnstarredVideosResult cannot report failed names. Partial database failures therefore look like complete success and produce no user warning. Test: Make one owned video update succeed and another fail, assert the response identifies both outcomes and the frontend warns about the failure, and verify a foreign video remains an intentional authorization skip.
• invokeai/app/api/routers/videos.py:193: Upload validation proves only that the MP4 container and first frame are decodable by the server. It does not validate a browser-supported codec or transcode the file, so HEVC and other MP4s may be accepted but remain unplayable. GalleryVideoThumbnail also has no error state when both the WebP and fallback video fail. Test: Verify an H.264 MP4 uploads and plays in supported browsers, while an unsupported-codec MP4 is rejected or transcoded and a failed fallback renders a stable error placeholder. Document the codec contract under docs/src/content/docs/features/gallery.mdx.
• invokeai/app/services/boards/boards_default.py:90: Every listed board performs two cover queries and three count queries, with another owner query for administrators. This PR adds two video queries per board and materially worsens the existing N+1 behavior for the unbounded all-boards view. Test: Instrument SQL query counts for one and 100 boards and require a constant bounded query count while preserving image/video covers and counts.
• invokeai/app/services/boards/boards_default.py:17: _resolve_cover() compares only (starred, created_at) and chooses the image on an exact tie, while the unified gallery uses kind and name tie-breakers that place the video first in descending order. A board cover can therefore disagree with its first gallery item. Test: Insert an image and video with identical starred state and timestamp, then assert the board cover matches the canonical gallery ordering.
• invokeai/frontend/web/src/features/imageActions/actions.ts:358 and invokeai/frontend/web/src/features/changeBoardModal/components/ChangeBoardModal.tsx:81: Video board moves fan out unobserved mutation promises and immediately clear selection or modal state. A mixed success and 403/500 result silently leaves only some videos moved with no actionable feedback. Test: Make one video move succeed and another fail, assert the failed selection remains or a partial-failure message identifies it, and verify the all-success case clears the state.
• invokeai/frontend/web/src/features/gallery/components/ImageGrid/GalleryVideoItem.tsx:158: The new gallery video item declares role="button" but has no tabIndex, keyboard activation handler, or accessible name. Keyboard and assistive-technology users cannot select or open it. Test: Tab to a video item, activate it with Enter and Space, and assert it has a meaningful accessible name and matches pointer selection behavior.
• invokeai/frontend/web/src/common/hooks/useDownloadImage.ts:8: The generalized video download path still reports toast.problemDownloadingImage, so a failed video download says "Unable to Download Image." Test: Fail an image and a video download and assert each receives accurate localized media wording.
• invokeai/frontend/web/src/features/gallery/components/ImageViewer/CurrentVideoPreview.tsx:181 and invokeai/frontend/web/src/features/gallery/components/ContextMenu/MenuItems/ContextMenuItemOpenInNewTabVideo.tsx:10: Playback uses the media-cookie refresh URL, but open-in-new-tab and download actions use the raw URL immediately. During restored-session cookie self-healing, these actions can return a permanent 401 instead of waiting for or retrying after the refresh. Test: Restore a valid bearer session without a media cookie, delay the cookie-refresh request, invoke both actions, and assert they complete after refresh; also verify a genuine authorization failure is not retried indefinitely.

[JPPhoto]

Prior items are fixed. Working on these now:

• invokeai/app/util/video_thumbnails.py:326 waits indefinitely on _VIDEO_STREAM_SLOTS and _VIDEO_DECODER_SLOTS before checking cancellation or applying a timeout. A canceled invocation can remain blocked behind another stream, and a decoder request with a short timeout can wait arbitrarily long for capacity. Test: occupy the stream slot, then verify canceled and timed-out consumers terminate before the slot is released.

• invokeai/app/api/routers/videos.py:379, invokeai/app/api/routers/videos.py:418, invokeai/app/api/routers/videos.py:783, and invokeai/app/api/routers/videos.py:814 perform synchronous database and filesystem operations directly inside async batch handlers. A request containing many videos can block the shared event loop and stall other users. Test: inject a slow synchronous delete or update and verify an async heartbeat continues for delete, uncategorized delete, star, and unstar.

• invokeai/app/invocations/wan_model_loader.py:116, invokeai/app/invocations/wan_model_loader.py:207, and invokeai/app/invocations/wan_model_loader.py:222 trust the resolved configurations for the main model, standalone T5 encoder, and component source without validating their model families and types. Stale or hand-edited workflow identifiers can resolve to valid non-Wan models and survive until a later incompatible model load. Test: provide realistic SDXL configurations for each identifier and require an immediate descriptive ValueError; retain the existing valid-Wan acceptance cases.

• invokeai/app/services/shared/sqlite_migrator/migrations/migration_2026_07_01_add_videos_tables.py:100 updates board_videos.updated_at using old.board_id. After a video moves boards, that key no longer identifies the row, so its timestamp remains stale. Test: insert an association with a fixed old timestamp, move it to another board, and verify both the board and timestamp change.

• invokeai/frontend/web/src/features/gallery/store/selectCachedGalleryItemNames.ts:23, invokeai/frontend/web/src/app/store/middleware/listenerMiddleware/listeners/boardIdSelected.ts:21, and invokeai/frontend/web/src/app/store/middleware/listenerMiddleware/listeners/appStarted.ts:32 only inspect getGalleryItemNames, while virtual boards are populated through getVirtualBoardItemNamesByDate. Range selection and post-delete neighbor selection receive an empty list, board switching clears selection after a five-second timeout, and initial selection never occurs when the restored board is virtual. Test: cover the cache selector, board-switch listener, and startup listener with a populated virtual-board cache.

• invokeai/frontend/web/src/features/auth/components/ProtectedRoute.tsx:45 handles removal of auth_token from another tab but ignores replacement with a refreshed token. Redux retains the old token, and invokeai/frontend/web/src/services/events/useSocketIO.ts:41 therefore reconnects Socket.IO with an expired credential until reload. Test: simulate a storage event containing a different non-null token and verify tokenRefreshed updates Redux and the socket configuration.

• invokeai/frontend/web/src/features/gallery/components/ImageMetadataViewer/VideoMetadataViewer.tsx:36 opens the protected video URL directly, bypassing the media-cookie self-healing path used by the other video open and download actions. Clicking during cookie restoration can open a 401 response even though the bearer session is valid. Test: require the metadata action to wait through openMediaInNewTab and reject a raw href={video.video_url} consumer.

• invokeai/frontend/web/src/features/changeBoardModal/store/slice.ts:7 and invokeai/frontend/web/src/features/deleteVideoModal/store/state.ts:26 retain newly added video names and pending dialog callbacks across both logout paths. Because these modals are mounted globally, another login can inherit the previous user's modal state and video identifier; the pending deletion promise also remains unsettled. Test: populate each state, dispatch both logout and sessionExpiredLogout, and verify names are cleared, dialogs close, and pending promises settle.

[JPPhoto]

Now working on:

• invokeai/app/util/video_thumbnails.py:210: _run_worker() starts its timeout only after acquiring _VIDEO_DECODER_SLOTS, so a saturated decoder pool can block indefinitely beyond the advertised timeout. Test: test_probe_timeout_includes_waiting_for_decoder_capacity holds all slots and verifies the caller times out while waiting.
• invokeai/app/api_app.py:181: _identify_video_upload_user() synchronously queries the user database from the ASGI event loop, so upload authentication can stall unrelated requests. Test: test_upload_authentication_does_not_block_the_event_loop injects a slow lookup and verifies an async heartbeat continues.
• invokeai/app/api/routers/boards.py:122: delete_board() performs the synchronous database and filesystem cascade on the event loop. The PR expands this work to include videos, increasing the potential stall. Test: test_delete_board_is_offloaded_by_fastapi verifies the route runs outside the event-loop thread.
• invokeai/frontend/web/src/features/auth/store/authSlice.ts:62: every cross-tab token refresh clears user, while invokeai/frontend/web/src/app/store/store.ts:269 resets the API cache even when the refreshed token belongs to the current account. Test: the same-account refresh tests verify the user and API cache remain intact.
• invokeai/frontend/web/src/app/store/store.ts:269: a genuine cross-tab account switch resets RTK Query but does not run the logout reducers that clear private gallery, prompt, and workspace state. The next account can inherit state from the previous account. Test: the account-switch tests seed private state, adopt another user's token, and verify it is cleared.
• invokeai/frontend/web/src/features/gallery/components/ImageMetadataViewer/VideoMetadataViewer.tsx:39: the raw href={videoUrl} allows browser context-menu navigation to bypass media-cookie self-healing, producing a 401 when the cookie has expired. Test: the metadata-link test verifies navigation waits for cookie repair.
• invokeai/frontend/web/src/features/gallery/components/ImageMetadataViewer/VideoMetadataViewer.tsx:45: the unguarded onAuxClick handles right-click as well as middle-click, so opening the context menu can unexpectedly open the video. Test: the pointer-button test verifies only primary and middle clicks open it.
• invokeai/frontend/web/src/features/gallery/store/selectCachedGalleryItemNames.ts:39: the virtual-board debounce fallback returns the first matching same-date cache entry, potentially selecting an older filter or sort result instead of the active entry. Range selection can then operate on names not displayed in the grid. Test: the cache-selection test verifies the most recently active compatible entry is used.
• invokeai/frontend/web/src/services/api/endpoints/images.ts:328: deleteBoardAndImages does not invalidate virtual-board summaries or uncategorized list and count caches. Successful deletions leave virtual covers and totals stale, while failed file deletions move media to no-board without refreshing no-board totals. Test: the endpoint-consumer test covers successful and partial-failure responses.
• invokeai/app/invocations/wan_latents_to_image.py:50: the node accepts batch sizes greater than one, decodes the complete batch, and then uses only img[0], silently discarding every other image. Test: test_multi_image_batch_rejected_before_vae_load covers 4D and single-frame 5D batches.
• invokeai/app/invocations/wan_denoise.py:353, invokeai/app/invocations/wan_video_denoise.py:123, and invokeai/app/invocations/wan_ref_image_encoder.py:79: multiple_of=16 accepts zero and negative multiples because no positive bound is declared. These values reach tensor allocation, image resizing, and VAE memory estimation. Test: test_spatial_dimensions_must_be_positive covers zero and negative width and height for all three nodes.
• invokeai/app/invocations/wan_denoise.py:447: supplied initial latents are used without validating rank, batch, temporal length, variant channel count, or requested spatial dimensions. They can broadcast against generated noise, override the requested output shape, or pass through a zero-step path as malformed output. Test: test_initial_latents_must_match_image_denoise_contract covers each contract.
• invokeai/app/invocations/wan_latents_to_video.py:90: empty temporal or spatial latent axes pass validation. A zero temporal axis produces a negative t_pixel, while zero spatial axes reach VAE loading and decoding. Test: test_empty_video_latent_dimensions_are_rejected_before_vae_load covers empty time, height, and width axes.
• invokeai/backend/model_manager/load/model_loaders/wan.py:301: the GGUF model is created under init_empty_weights(), but the result of load_state_dict(..., strict=False) is ignored. A checkpoint missing a transformer parameter is returned with that parameter unmaterialized and fails later during generation. Test: test_gguf_loader_rejects_missing_model_parameter supplies a missing attention weight.
• invokeai/frontend/web/src/features/gallery/store/gallerySlice.ts:60: selectionChanged() clears image comparison whenever any selected item is a video, even when the active last item is an image. A mixed selection ordered as video then image therefore disables valid image comparison. Test: keeps comparison when the active item in a mixed selection is an image reproduces this ordering.

[JPPhoto]

@lstein Your turn to review.

[lstein]

@JPPhoto — thanks for the two follow-up commits (f008515, 11b3869). I reviewed both and fixed the one CI failure they introduced. Summary below.

CI fix (pushed as e56ea845c4)

Only one job actually failed (py3.12: macos-default); the other five were fail-fast cancellations. The test commit (f008515) still drove the star/unstar dedupe test through asyncio.run(route(...)), which was correct when written — but the fix commit an hour later (11b3869) converted those routes from async def to sync def, so asyncio.run received a plain StarredVideosResult instead of a coroutine. I changed the test to call the routes directly. Verified locally: 794 backend tests + 60 frontend tests pass, ruff@0.11.2 lint/format clean. CI is rerunning on the new head.

Review — no blockers

The changes look solid and close out the remaining review items:

• Sync-def route conversion (delete_videos_from_list, delete_uncategorized_videos, star/unstar, delete_board) is the right fix for the event-loop blocking — FastAPI offloads sync handlers to its threadpool, which is cleaner than sprinkling run_in_threadpool inside async handlers. The middleware's _identify_video_upload_user_async wrapper with the inspect.isawaitable shim complements it nicely.
• board_videos trigger fix (old.board_id → new.board_id) is correct — the AFTER UPDATE trigger must locate the row by its new board_id or a board-move never gets its updated_at stamped.
• Bounded semaphore waits in video_thumbnails.py: the capacity wait is now deadline-bounded, cancel-aware, and releases acquired slots in a finally; the new test proving the probe timeout includes the capacity wait is a good pin.
• Wan loader hardening: validating every identifier against its resolved config closes the forged-identifier gap, and raising on missing_keys in the GGUF loader prevents silently running a partially-initialized transformer. The latent-shape validation on the denoise/decode nodes is thorough and each rule has a matching test.
• Cross-tab account switching (externalTokenAdopted) is a genuinely good design — full logout() reduction before adopting a different user's token, RTK Query reset, pending dialogs settled, same-user refreshes preserved. This closes the cross-tab data-leak case cleanly.
• Virtual-board cache awareness: I verified the hand-built query args in boardIdSelected.ts / selectCachedGalleryItemNames.ts match use-gallery-image-names.ts's subscription shape exactly (categories ?? undefined, search_term || undefined), so the cache lookups will hit.
• Replacing the flaky heartbeat-timing tests with inspect.iscoroutinefunction assertions is a smart trade — it pins the offload contract without wall-clock sensitivity.

Minor observations (non-blocking; fine to leave or fold into the follow-on PR)

1. Inconsistent conversion: single-item delete_video and update_video are still async def doing the same sync SQLite work as their now-sync batch siblings, so those two still block the event loop. Low impact (single-row operations), but worth a follow-up for consistency.
2. The migration edit won't reach existing dev DBs: dated migrations run once, so any install that already ran migration_2026_07_01_add_videos_tables keeps the buggy trigger. Fine for an unreleased branch, but our dev databases may each be carrying the old trigger.
3. iter_video_frames timeout semantics: the capacity wait gets its own full timeout budget and then the decode gets the full timeout again — worst-case wall time is 2× timeout. Defensible, just not obvious.
4. VideoMetadataViewer link: href="#" with click interception means right-click → "open in new tab" opens #. Primary/middle-click paths are covered; cosmetic edge only.

🤖 Generated with Claude Code

[JPPhoto]

Working on...

• invokeai/app/invocations/wan_denoise.py:399: Image denoising does not validate the reference condition tensor's rank, batch size, 20-channel width, single-frame temporal size, or latent spatial dimensions. Malformed tensors fail later with opaque PyTorch errors. Test: Added rank, batch, channel, temporal, and spatial negative cases to tests/app/invocations/test_wan_denoise.py; the existing valid-shape test provides the positive case.

• invokeai/app/invocations/wan_video_denoise.py:253: Video denoising leaves rank, batch size, A14B channel count, and spatial dimensions unchecked. A TI2V condition with batch size 2 is silently accepted and changes the output batch size; other malformed shapes fail downstream. Test: Added A14B and TI2V negative cases to tests/app/invocations/test_wan_denoise.py, alongside existing valid-condition tests.

• invokeai/frontend/web/src/features/gallery/components/ImageMetadataViewer/VideoMetadataViewer.tsx:38: The protected video link uses href="#". Browser context-menu actions bypass the click handlers, so "Open link in new tab" opens the current page instead of the video. Test: Added a regression assertion to invokeai/frontend/web/src/features/auth/store/protectedMediaConsumers.test.ts.

[JPPhoto]

@lstein It looks like we were thrashing on the async route findings because the review was treating one implementation approach as the contract instead of focusing on observable non-blocking behavior. I narrowed the remaining work to agreed, PR-scoped issues, added complete Wan reference-condition tensor validation, and replaced the metadata link's fake # target while preserving its protected-media behavior.

[lstein]

@JPPhoto My coding agent (Claude Code running Opus 5) has completed its review of your recent fixes and concluded that you have successfully addressed two of the four non-blocking issues raised in its previous review. The remaining two issues (async calls for the single-item routes and the worst-case 2x timeout in iter_video_frames) can be deferred, I think, to follow-on single-issue PRs.

Up to you, but I think we're ready to merge.