Repository navigation
Migrated host: picker lists uploads with 'image' prepended, so the exact-name frame/ref search never binds — video i2v is unreachable by either route #860
Description
Summary
On the migrated flow.google.com host, the media picker lists an upload with image
prepended to its display name, and the picker search matches on the exact stem — so it never
binds. The searched name is a substring of the listed name, which the error message itself
prints side by side:
the frame picker lists no asset named 's1-cbbc098b.jpg' after 3 searches of 8s
(media d1c34471-eb88-486e-ae56-3624503abfda) — the tag after the stem is expected: gflow
uploads under a run-unique display name so the search cannot bind an older copy of the same
file (#792). The picker listed: 'images1-cbbc098b.jpg'
s1-cbbc098b.jpg vs images1-cbbc098b.jpg — same run-unique tag, same stem, one image
prefix. The upload succeeded (migrated.frame_uploaded, and the media UUID is in the message);
only the read-back match fails.
This blocks video production entirely on a migrated account, because both routes to a start
frame are closed:
| route | result |
|---|---|
--initial-frame <local file> |
exit 32 — this bug, frame_search_miss ×2 |
--initial-frame <media UUID> |
exit 36 — "a frame given by Flow media UUID is not ported yet (#639)" |
To be clear about what works well: both refusals are pre-submit and cost nothing. The exit-32
guard is doing exactly its job — a clip with no start frame would have been full price and
useless. This report is about the match, not the guard.
Environment
- gflow-cli 0.77.1 (PyPI), Python 3.13.7, Windows 11
- Account migrated to
flow.google.com; profile created viagflow auth login --browser chrome - Same profile generates
image t2i/i2ifrom local files without trouble
Reproduce
gflow video i2v --initial-frame ./stills/s1.jpg "<motion prompt>" \
--model veo-lite --count 1 --project <id> --profile <name> \
--out-dir clips --json
Event trace — upload fine, match fails twice:
migrated.model_selected
migrated.settings_applied
migrated.frame_uploaded
migrated.frame_search_miss
migrated.frame_search_miss
error_raised
The same signature on the image path
image i2i fails identically when a ref has to be found after upload — we hit it on one asset
six consecutive times before giving up and removing the reference from the shot:
ReferenceNotFoundError: migrated host: clearing the failed
's025_elem_book_full-0040ac56.jpg' query removed an already-attached reference
(2 chip(s) before, 1 after) — the prompt is no longer the one that was built,
so this run is abandoned rather than submitted
Same shape: frame_uploaded ×3, then the lookup for one of them misses. If the picker prefixes
there too, s025_elem_book_full-0040ac56.jpg would be listed as
images025_elem_book_full-0040ac56.jpg and could never match either. Worth checking whether one
fix closes both.
Note the second-order effect in that message: clearing a failed query removed an
already-attached chip (2 → 1). Abandoning the run is the right call, but a failed search
mutating state that had already succeeded looks like its own bug.
Suggested fix
Match the picker entry by suffix or containment on the run-unique tag rather than by exact
display name. The tag (-cbbc098b) is already unique per run, which is what #792 introduced it
for, so endswith(f"{stem}-{tag}.jpg") — or simply matching on the tag — binds correctly whether
or not Flow decorates the label. That also survives any future prefix/suffix Flow adds, which an
exact match cannot.
Worth confirming whether image is a real prefix in the DOM or two adjacent nodes being read as
one string (a type label followed by the filename would concatenate exactly this way). If it is
the latter, reading the filename node alone fixes it at the source.
Impact
Video is unreachable on a migrated account: video i2v cannot be given a start frame by either
route. For a story pipeline that animates approved stills, that stops production at the last
step — we have 11 approved stills and cannot animate any of them.
Related
- Flow's migrated flow.google.com frontend: text-to-video is driven (v0.67.0); image, i2v/r2v, characters, scenes, extend, instructions, tools and project creation still pending #639 — migrated feature matrix; UUID frames listed as unported, which closes the other route
- video: portrait (9:16) dispatch fails with UiSelectorDriftError — driver captures a blank page while the app is live (reproducible; landscape OK) #792 — introduced the run-unique display-name tag this search depends on
- media picker: prompt-derived search_hints cannot match Flow captions #541 — prompt-derived search hints cannot match Flow captions (different cause, same surface)
- feat: refresh-on-miss display-name resolution — rename self-healing in the picker path #546 — refresh-on-miss display-name resolution (closed); this miss is not staleness, the
asset is listed, just under a decorated name
Activity
ffroliva commentedon Sep 17, 2026
Confirmed from the Flow UI: the
imageprefix is not Flow's, it is an icon node being read as text.The project's media tile renders as an image glyph followed by the filename:
Two adjacent DOM nodes. Read together they produce
images1-cbbc098b.jpg, which is exactly thestring the error reported the picker listing — while the asset's real display name is
s1-cbbc098b.jpg, the one gflow searched for. Nothing is renaming anything; the accessible/textcontent of the tile just includes the icon's label.
That narrows the fix from "match loosely" to "read the right node":
-cbbc098b) by containment, which survives whatever decorationthe tile carries
The second is the more durable of the two — the tag exists to be unique per run (#792), so it is
a better key than a display name that is only as stable as the surrounding markup.
Same surface, same session:
image i2ifailed six consecutive times bindings025_elem_book_full-0040ac56.jpg(migrated.mention_miss) until we removed the reference fromthe shot. Consistent with one concatenation bug behind both paths.
ffroliva commentedon Sep 17, 2026
Correction to my last comment, and the fix is up as a draft PR.
I wrote that the
image i2ifailures ons025_elem_book_full-0040ac56.jpg(
migrated.mention_miss) were "consistent with one concatenation bug behind both paths".That was a guess, and reading the path says otherwise.
_mention_by_name(migrated_composer.py:1871) never matches text at all — it types@+ the name, waits, presses Enter, and then counts mention chips. There is no_exact, nofilter(has_text=…), nothing an icon node could break. Whatever is failingthere is the mention plugin's own highlight or the server-side asset search, not the
concatenation. Two bugs, one surface. The mention half stays open and unexplained here;
it needs its own capture.
What is fixed is the half this issue names. Root cause,
migrated_composer.py:1980:_exactanchors both ends (^\s*…\s*$), so a tile whose text is the icon ligatureconcatenated with the file name can never match. Only this one call site was wrong — the
other three
_exactcallers (amat-iconligature, two aspect-ratio radios) are matchinga node's own text and stay as they are.
Reproduced in a real browser, $0.
tests/features/frame_picker_binding.featureservesa picker tile as
<mat-icon>image</mat-icon><span>name</span>through route interception —no Google, no profile, no credits. Chromium reports the option's text as
imagehero-ab12cd34.png, the same shape as theimages1-cbbc098b.jpgthis issue was filedwith, and the anchored matcher fails on it in 3/3 searches. This is deliberately an e2e and
not a unit test: a fake locator returns the list the test wrote into it, so the mocked
version of this test passes against the bug.
The fix is containment on the display name rather than an anchored match. That does not
give away what #792 bought: the name carries a run-unique tag, so a library still holding
yesterday's copy of the same stem cannot win the match — there is a scenario pinning
exactly that, and a third one proving an asset the picker genuinely does not list is still
refused with exit 32.
fix(migrated): bind a Frames picker option by containment, not an anc…
fix(errors,migrated): stop reporting two things we never observed (#803…
chore(release): v0.78.0
ffroliva commentedon Oct 23, 2026
Verified live, 2026-10-23 (ffroliva, flow.google.com, develop 29171fd).
tests/e2e/test_migrated_host_e2e.py::test_e2e_end_frame_binds_the_second_chip_and_submits_interpolation: 1 passed (64 s). Both local frames uploaded (migrated.frame_uploaded×2), bound through the Frames picker by containment (#866), and the intercepted submit body carried both. The submit was aborted, so nothing reached Flow and nothing was billed.That is the one real i2v binding PR #866 asked a human to watch before closing (
Refs #860). The separate@-mention miss noted in the thread is a different path. Theimage i2ilocal-reference e2e passed in the v0.88.0 release run, so if a mention miss shows up again it gets its own issue with a capture.