Repository navigation
video i2v: accept an in-project asset (media UUID) as --initial-frame instead of forcing a local-file upload #287
Description
Motivation (live incident, 2026-07-11)
Running the chalkboard i2v pilot on 0.31.0: the scene stills already exist as assets in the standing Flow project (f6caf027), but gflow video i2v only accepts --initial-frame FILE, so every generation re-uploads a local copy.
Concrete cost today:
s1.jpgwas rejected by the Flow upload endpoint with HTTP 400 (ui_automation_video.image_uploadedstatus 400 → unhandled RuntimeError, exit 1), while byte-identical-format siblings s7/s11 uploaded fine. Re-encoding withffmpeg -q:v 2 -map_metadata -1fixed it — some metadata segment in the original upset the endpoint. None of this would have happened selecting the existing in-project asset (d6f1927a-3eae-4626-bc90-9a6ea7637bab).- Duplicate assets pile up in the project library (same duplication we eliminated for image refs via the Reference picker: only the first --ref <uuid> is selectable; later UUIDs time out (virtualised grid never scrolled) #282 picker fixes).
Proposal
Accept a media UUID for the initial frame, e.g.:
gflow video i2v --initial-frame-media-id d6f1927a-... "motion prompt" --project f6caf027-...
(or detect a UUID passed to --initial-frame). The selection machinery already exists — _select_existing_asset in ui_automation_video.py got scroll/search fixes in #282; this is about exposing it on the i2v CLI surface (and --end-frame for symmetry).
Secondary finding
The HTTP 400 upload rejection surfaces as error_unhandled / generic UnexpectedError (exit 1, retryable: false) with no hint that the input image was refused. A typed error ("Flow rejected the initial-frame upload (HTTP 400) — try re-encoding the image") would have saved the diagnosis round-trip. Consider folding into #283.
Activity
Merge pull request #290 from ffroliva/feature/287-i2v-asset-ref
ffroliva commentedon Jul 11, 2026
Shipped in PR #290 (merged to develop, releasing in v0.32.0) and live-verified end-to-end:
--initial-frame <UUID> --project <id>selected the in-project asset with zero upload events and produced a real 720×1280 interpolation (frame_ref_attached→batchAsyncGenerateVideoStartImagewith the asset bound). The secondary ask also shipped: anuploadImage4xx now raisesMediaUploadRejectedError(exit 27) with the re-encode hint instead ofUnexpectedErrorexit 1. A live 400-repro remains open-ended (the original s1.jpg is gone) — the KNOWN_ISSUES entry on the metadata-sensitive rejection tracks that behavior.ffroliva commentedon Jul 11, 2026
Live feedback on 0.32.1 (candle production run, 2026-07-11): the UUID path works as designed in lean projects, but in the standing production project (~100+ assets after two days of runs)
gflow video i2v <uuid> --project f6caf027…fails withTransportTimeoutError: 'Start frame asset … could not be located in the media picker'. The asset is definitely in the project (generated there this afternoon, UUID from the local catalog). Looks like the picker's scroll/search gives up before the virtualized grid reaches the tile in large projects — same shape as the #283 off-by-one but a depth/timeout budget rather than a missed final scroll. Workaround used: local-file upload fallback. Suggest: bound the scroll by grid-total (picker reports asset count?) rather than a fixed attempt budget, or fall back to the display-name search with the UUID-derived filename. Bonus confirmation: omitting--durationon the affected cohort behaves exactly as the #288 fix documents.ffroliva commentedon Jul 11, 2026
Full reproduction details (we own the profile/project — stable repro from this machine):
denon82(local Chrome profile dir%LOCALAPPDATA%\ffroliva\gflow-cli\profile_denon82)f6caf027-ad68-49e3-aac9-ee32f1582bf3(standing production project, ~100+ media assets accumulated 2026-07-10/11)2f72aa2a-5081-4df8-a3b1-64b6a859274c— image generated in THIS project 2026-07-11 ~17:12 viagflow image i2i(classic path), present in the local catalog and visible in the Flow web UI media gridCommand:
Result:
TransportTimeoutError(exit 9): "Start frame asset '2f72aa2a-…' could not be located in the media picker — is it in the target project (missing or wrong --project), and is the UUID from this profile's local catalog?" Both preconditions hold, so this is the picker scroll/search budget, not user error.Control: the same command shape succeeds in a freshly-created scratch project (single-digit asset count) — verified same day.
The repro costs 0 credits (failure occurs at frame selection, before generation submit), so it's safe to iterate against. We'll take a run at the fix from this environment on a
bugfix/branch againstdevelop.ffroliva commentedon Jul 11, 2026
Root-cause hypothesis (from the project owner, who knows the Flow UI): the media picker's library component has its own project selection component and its grid/search is per-project, not all-projects.
--projectnavigates the editor to the target project, but the picker's library can open on a different active project (plausibly the most-recently-created one). This explains all observations at once: the asset never appears at any scroll depth (wrong grid entirely); UUID selection worked in fresh scratch projects (the scratch WAS the picker's active project); and #282-era selections worked in the standing project back when it was the most recent. Fix direction being implemented onbugfix/287-picker-scroll-depth: before tile lookup, read the picker's active project and switch it to the target when they differ (guarded no-op when the selector is absent), with the progress-bounded scrolling + search tiers kept as hardening. Instrumentation (structured picker events + bounded DOM dump incl. the project-selector state on failure) lands with it, so the next live run against the crowded-project repro is decisive either way.ffroliva commentedon Jul 11, 2026
Fix live-verified on
bugfix/287-picker-scroll-depth(6 commits, ebce115..f9bf0cf): the original repro —gflow video i2v <uuid> --project f6caf027…in the ~100+-asset standing project — now completes end-to-end (picker_scroll_done reason=found attempts=4→video_saved). Actual root cause:_scroll_picker_gridwas a blind hover+mouse-wheel that react-virtuoso ignored — a silent no-op indistinguishable from end-of-grid, hence every 'scrolled N times, tile never rendered' outcome. The fix JS-scrolls the dialog's real scrollable node with scrollTop telemetry. Along the way (all kept): picker project-alignment machinery + document.title name derivation (+--project-nameescape hatch + env var), prompt-search hints from the local catalog, population polling, and full picker telemetry + failure DOM dumps. Note for the record: the 'wrong project' theory from earlier comments was a mirage — the standing project's display name is literally 'gflow-cli t2i'. Suite: 2269 passed, 90% coverage, all gates green. Branch is local, unpushed — ready for the 0.32.x train.Merge pull request #296 from ffroliva/bugfix/287-picker-scroll-depth
feat(image): dedup i2i refs via picker filename search instead of re-…
refactor(image): #314 dedup robustness — scroll fallback + shared att…
docs: sweep re-verify nits (provenance wording, #287 version attribut…
docs: asset-tagging (@-mention) research recon + design spec + implem…
feat(video): i2v frames accept an in-project asset UUID; typed upload…
fix(picker): progress-bounded grid scroll + UUID search tiers reach d…
3 remaining items
feat(picker): --project-name override, title-derived name, menu scrol…
fix(picker): prompt-search hints + virtuoso-node grid scroll; project…
feat(video): i2v frames accept an in-project asset UUID; typed upload…
Merge pull request ffroliva#290 from ffroliva/feature/287-i2v-asset-ref
fix(picker): progress-bounded grid scroll + UUID search tiers reach d…
fix(picker): sync library view to target project + ffroliva#287 diagn…
fix(picker): switch library project by resolved NAME via Radix submenu (
fix(picker): poll portal population + sweep generic clickables + raw …
feat(picker): --project-name override, title-derived name, menu scrol…
fix(picker): prompt-search hints + virtuoso-node grid scroll; project…
Merge pull request ffroliva#296 from ffroliva/bugfix/287-picker-scrol…
feat(image): dedup i2i refs via picker filename search instead of re-…
refactor(image): ffroliva#314 dedup robustness — scroll fallback + sh…
docs: asset-tagging (@-mention) research recon + design spec + implem…
docs(529): scenario + implementation plan for media-picker tier reorder