Index InvokeAI board videos alongside board images

[lstein]

An InvokeAI board holds videos next to its images and its gallery shows both, so a board-backed album now indexes both. This removes the board-video restriction added in #361, which skipped them explicitly pending a verified delete path.

What changed

InvokeAI client

• fetch_board_video_names() lists a board's videos. Videos are a separate resource over there: their own router, the board passed as a query parameter rather than a path segment, and a VideoNamesResult object instead of the bare array the images endpoint returns. The same is_intermediate=false + categories=general,user filtering as images applies, and it matters — a Wan pipeline writes its intermediate clips to the board too (a real board listed 52 unfiltered vs 48 filtered).
• A backend predating the video API 404s the whole router, which reads as "no videos here" rather than a failed index run, so board albums on an older InvokeAI keep indexing their images.
• delete_video() routes deletions to the video endpoint. It also checks failed_videos, because that endpoint can report a failure inside a 200 — accepting it would drop the local index row while the video stayed on the board, and the video would reappear on the next re-index.

Board albums

• Both output directories are derived now (outputs/images and outputs/videos). image_paths is what gates file access and relative-path resolution, so a board video would otherwise index but be refused at playback. The paths are recomputed on every construction, which is how albums written before this pick up the videos directory with no migration step.
• Deletions dispatch on suffix: sending a video name to the images endpoint just 404s, which the client reads as "already gone" and swallows.
• The missing-on-disk discrepancy warning and the "board is empty" error now count both media types.

Verification

Backend 679 passed, frontend 578 passed, ruff clean.

Verified end-to-end against a live InvokeAI: 48 videos + 2 images resolved off a real board, through the auth fallback, with frame extraction and probe facts intact.

Note on the merge commit

Master's video work (#358–#362) landed while this was open. embeddings.py took master's side wholesale — its video indexing is a superset of what this branch had grown independently — and _resolve_board_album_files kept this branch's. Details are in the merge commit message. Since PRs here are squash-merged, the merge commit disappears on landing.

🤖 Generated with Claude Code

[lstein]

Adversarial review

Three fresh-context agents attacked this branch on separate lanes (config path derivation, the InvokeAI client + delete dispatch, indexing pipeline + test honesty). Every claim below was verified against both this code and the InvokeAI checkout it talks to. Baseline reproduced clean at a826b8e: 679 backend tests passed.

Everything found is fixed in 87061d6.

Confirmed defects

1. delete_video crashed on a 200 whose body is not a JSON object — invokeai_client.py

response.json().get("failed_videos") was guarded only against ValueError. A 200 carrying a JSON array/string/null raised AttributeError, surfacing as a 500 after InvokeAI had already deleted the video — leaving the index row pointing at a file that is gone, which is the exact inconsistency the failed_videos check exists to prevent. Its sibling fetch_board_video_names already guarded the same hazard with isinstance(payload, dict).

2. Single-delete of a board video orphaned its extracted still — routers/index.py

The board branch returned before _discard_cached_frame; the non-board branch and the batch endpoint both call it. Inert before this PR, because a board album could not hold a video.

3. A falsely-empty video listing silently pruned already-indexed videos — invokeai_client.py → routers/index.py → embeddings.py

fetch_board_video_names returned [] on 404, so _resolve_board_album_files reported missing == 0, update_index_async classified every previously-indexed board video as missing, _filter_missing_images dropped the rows and _prune_video_frame_cache deleted their stills — and the run reported completed with no warning. Note the asymmetry: every other status raises 502 and preserves the index; only the destructive case was silent. Reachable via a reverse proxy that routes /api/v1/images but not /api/v1/videos, or an InvokeAI downgrade.

4. "A 404 cannot mean anything else here" is false — invokeai_client.py

InvokeAI's get_video_names calls assert_board_read_access, which raises 404 "Board not found" for a non-admin caller (invokeai/app/api/routers/_access.py:81-84). What actually saved the code was an undocumented ordering coupling — _resolve_board_album_files fetches image names first, and the boards router 404s an unknown board for all users, so the run already 502s before the video call. Separately, the return [] sat inside the per-board loop, discarding names already collected from earlier boards.

5. _delete_board_media's stated rationale was wrong — routers/index.py

It claimed a video name sent to the images endpoint "just returns 404". InvokeAI's DELETE /images/i/{name} wraps its lookup in a bare except Exception: pass and returns 200 with an empty deleted_images (invokeai/app/api/routers/images.py:213-226) — a mis-dispatch would read as success, not as a swallowed 404. The dispatch is right; the reasoning was not.

Lower severity

• Permanent false warning: the derived <root>/outputs/videos made Image path does not exist fire on every Album construction for any InvokeAI that has never produced a video — i.e. most installs, on a correct configuration.
• Misleading fatal error: a board holding only videos, none on disk, hit missing and not existing → 502 blaming outputs as a whole, when only the videos directory came up empty. Pre-PR that album completed with "contain no images".
• Test gaps: test_missing_board_video_is_skipped_not_fatal was marked @requires_ffmpeg but never touches a video file — and it was the only coverage of the new two-directory missing arithmetic, so on ffmpeg-less platforms that accounting had none. min_image_bytes: 0 in the board fixture was unnecessary (the bundled images clear the 8192 default; videos bypass the gate outright) and its comment was inaccurate. Nothing covered the legacy single-path album gaining the videos directory, nor a board video actually serving through /videos/… — the entire stated justification for the image_paths change.

Attacks that failed

Suffix mis-dispatch (InvokeAI names are {uuid}.png/{uuid}.mp4 unconditionally and video upload accepts .mp4 only, so #361's is_video filter was defensive — removing it is safe); images↔videos name collisions (disjoint suffix allowlists on the serving routes, thumbnail keys hash the extension); config round-trip idempotence and ~/symlink/relative-root handling; the late-binding closure over params in the per-board loop (correctly pinned); batch-delete consistency (per-item try/except, rows dropped only after a successful remote delete, single npz rewrite); auth-fallback loops or token poisoning; videos being rejected by the scan gate; progress-tracker stuck states on 502; and every downstream path from #358–#362 (umap media filter, duplicate detection, zip/curation export, the recall guard) behaving identically for board and directory videos.

What changed in 87061d6

fetch_board_video_names now returns BoardVideoNames(names, api_available), so "this board has no videos" and "we could not find out" are different facts to the caller; a run that loses rows to an unanswered listing says so, counting only the videos actually being pruned rather than every indexed video. Plus the shape guard in delete_video, the frame-cache discard on board delete, the two corrected rationales, the warning exemption for derived board directories, a per-kind "none found" error, and seven new tests (end-to-end video serving, frame-cache discard, both outage shapes including the partial listing that must not claim videos were dropped, the videos-only error, the legacy path migration, and a non-object delete body).

The fixes went through two further adversarial rounds. The first found three real defects in them — the drop count included videos being kept, the empty-album error still asserted "no videos" during an outage, and the count primed a path-keyed lru_cache immediately before a possible unlink(). All three are fixed and mutation-verified (each new test fails with its production hunk reverted); the second round found nothing new.

Backend 691 passed, ruff clean.

Out of scope

Filed #371 for a pre-existing bug this widens: bookmarks.js's "Move to folder → Add Folder" POSTs a partial update_album/ payload, and update_album defaults source_type to directory — silently demoting a board album, after which deletions stop routing through InvokeAI and the next index scans outputs/images and now outputs/videos as plain directories.

Two other pre-existing items left alone: _request_with_auth_fallback treats a genuine 403 as "backend went single-user" (now more reachable, since the video endpoints have real 403 sources), and delete_image never inspects deleted_images — adding that check would break the legitimate "already gone" path, so it needs its own design.

🤖 Generated with Claude Code