[ffroliva]

Summary

Fixes #719 shape A. Builds on the instruments and findings in #754.

Flow holds an account's first upload behind a one-time "Rights to use this image" confirmation. It renders after the file chooser hands the file over — so _dismiss_dialog, which runs back in ensure_editor, never sees it — and Flow sends nothing until a human accepts it. The driver spent its full 60 s budget waiting for a request the page had already declined to make, then reported:

MediaUploadRejectedError (exit 27): migrated host: no maseQ reply within 60s of choosing
the file — the upload never reached Flow or was dropped

…and advised re-encoding the image to strip metadata. Neither the file nor the network was ever involved. This blocked both video i2v --initial-frame and video r2v --ref, which is every form that binds a local file on this host.

The guard

dialogs_before = await page.locator(DIALOG).count()
await chooser.set_files(str(image_path))
try:
    status, text = await asyncio.wait_for(reply, timeout=FRAME_UPLOAD_S)
except TimeoutError:
    try:
        opened = await page.locator(DIALOG).count() > dialogs_before
    except Exception:            # a probe is never the failure it reports
        opened = False
    if opened and not sent:      # `sent` comes from a request listener
        raise MediaUploadRejectedError(detail=..., remediation_hint=...)
    raise MediaUploadRejectedError(...)   # now says whether the request left the page

It sits in _upload_via_toolbar, where i2v --initial-frame and r2v --ref already converge, so one check covers both surfaces.

It counts dialogs rather than matching one, and that is the load-bearing decision. The dialog's two buttons are button.flow-button-medium with no ligature and no data attribute, separable only by DOM order, and its copy is translated — there is no anchor there that satisfies this project's locale-invariance rule. "A dialog appeared between the file being chosen and the wait expiring" is upload-related by construction: it needs no selector, and it cannot rot when Angular renames a class.

The _default_remediation ("re-encode the image to strip metadata") is not changed — it is still correct for the original #287 case, a 4xx on one file's metadata. It is overridden on this branch only.

gflow does not accept the dialog, and there is no flag to make it

The dialog affirms that you hold the rights to the content being uploaded. That is not a claim a script may make on an account owner's behalf. It is also one-off per account, on a path that already requires an interactive gflow auth login — so the manual step costs 30 seconds once in an account's life, and automating it would assert something on the user's behalf to save nothing.

No config flag either: a setting that can never safely default to on, for an event that happens once, is a flag nobody sets.

Verification

Measured live on ci-probe (#754 carries the instrument). The order was forced — the dialog is one-off, so the guard had to be written and verified against the live dialog before anything was accepted, or the failing state would be gone forever.

#	Run	Result
1–3	upload, pre-fix	no maseQ reply within 60s — the misleading message
4	upload, with this guard	a dialog opened after the file was chosen and no maseQ request was ever sent — Flow is holding the upload behind its one-time upload-terms confirmation (the pre-review wording; it is now hedged to "most likely" and backed by an observed request listener — see below)
5	accept (owner-authorised) → retry, same session	media_id 8914400f-…
6	plain upload, fresh session	uploaded, dialog: None, 4 POSTs

The dialog blocks the send (4), accepting unlocks it (5), it never returns (6).

Offline: 90 tests in test_migrated_composer.py, full tests/api/transports suite, and the nine local gates.

/code-review high ran before this PR, and found three things

Per the process change from #752 — the gate goes before the merge, not after. All three are fixed in this branch:

1. The dialog probe could become the failure it describes. The count() runs inside except TimeoutError, and the likeliest reason no reply arrived is that the page died or navigated — in which case the count raises too, escapes in place of MediaUploadRejectedError, and the run exits with an unmapped code 1 and a traceback instead of the mapped 27 with its remediation. Before this change the timeout path had no awaits and could not fail that way. It now degrades to the plain timeout. Same lesson as Follow-up on #751: code review found 13 issues in the agent-mode fix, 2 of them real defects in the tests #752, one surface over.

2. The message asserted two things the code never observed. "no maseQ request was ever sent" was inferred from a response listener, so a request that did leave and was answered slower than FRAME_UPLOAD_S produced it falsely — and that constant's own comment concedes a 20 MB file on a slow link needs longer. Fixed by watching the request too, which is worth more than the wording: sent now splits migrated host: an upload request leaves the page and Flow never answers (intermittent, ~1 in 4 on a consented account) #719 shape A (nothing left the page) from shape B (it left, Flow didn't answer) at the point of failure, and those argue for opposite fixes — one for a retry, one against. That is exactly what the spike doc recommended, and it costs one boolean.

   "Flow is holding the upload behind its one-time upload-terms confirmation" was asserted as fact from a bare dialog count, so any modal in that window inherited it — an error modal, a quota notice, a re-login prompt. It now says "most likely", and the remediation tells a user who sees a different dialog that that is the one blocking them. A count is evidence for a guess, not a fact — which is the whole thing migrated host: an upload request leaves the page and Flow never answers (intermittent, ~1 in 4 on a consented account) #719 is about.

3. A #: block documented an UPLOAD_CONSENT_DIALOG constant that was never defined, so it dangled between DIALOG_CLOSE and SUBMIT_RPCS and the guard's comment pointed at a name not in the file. I caught this one myself reading the diff, before the review returned it. Nothing to rename — the guard counts precisely so it needs no selector — so the rationale moved to the guard.

Four unit cases, and the last two came out of the review:

• the terms branch produces the new message and drops the wrong "re-encode" advice;
• a control proving the guard does not fire on a dialog that was already open — otherwise a lingering changelog modal (Handle Google Flow changelog overlays before UI interactions #26) would rewrite every unrelated upload timeout into a terms message and send the user to accept something never asked of them. The plain-timeout test also now asserts the terms wording does not leak onto it;
• the shape-B wording on a request that left the page and went unanswered;
• exit 27 surviving a probe that dies mid-upload — the regression the review found.

The fake now models the upload request leaving the page, and a page that dies once the file is handed over, so both states are constructible rather than argued.

On the Iron Law — why there is no new e2e for the positive branch

The guard's firing branch was verified live (run 4 above, against the real dialog), and that is the strongest evidence available for it. It is also unrepeatable: the dialog is one-off per account, and all three accounts on this machine have now accepted it. Reproducing the un-consented state needs a Google account that has never uploaded on flow.google.com — a named external blocker, not a skipped step.

The non-firing branch is where the regression risk actually lives (a guard that fires wrongly would mislabel every unrelated upload timeout), and that is covered offline by the control test plus the existing e2e_video i2v/r2v tests, which exercise the healthy upload path end to end.

If a fresh account ever appears, scripts/dev/spike_migrated_upload_wire.py (#754) reproduces the whole six-run sequence, including --accept-terms.

KNOWN_ISSUES.md corrected

The entry for this dialog said:

Affects: the legacy in-tree Compiled Growth worker, NOT gflow-cli itself … gflow-cli's API-driven path bypasses this dialog entirely (the REST endpoint already implies acceptance). Workaround in gflow-cli: none needed.

True of the REST path, and false since the migrated driver began using the editor's own upload — so the entry a user hitting #719 would find was reassuring them about the exact thing breaking their run. Rewritten with the measurement, the one-off workaround, and why gflow does not click it.

Scope

Not fixed here: #719 shape B — 1/4 on a funded account, the maseQ POST goes out with 8 675 B, no reply arrives, and 2.6 s later the whole project-load rpcid inventory fires. Unrelated to consent, still open, and #719 stays open for it.

MCP parity: no CLI leaf, option, queued-payload key or tool docstring claim changes. The guard is in the shared transport, so the MCP twin gets the improved error for free — same code path, no adapter change.