Windows 0.72.0: local-reference R2V times out after migrated.editor_ready, before submit

[frankico]

Summary

On Windows with gflow-cli 0.72.0, local-reference video r2v reaches migrated.editor_ready on flow.google.com, then exits with an unhandled Playwright TimeoutError about five seconds later. No output video is written. The same failure fingerprint occurred on 0.71.1.

Related: #749 (closed) and #752 for settings/composer behavior; #722 for post-teardown incident snapshots. I cannot establish the precise failing locator from the available evidence.

Environment and invocation

• Windows, Python 3.12.14, Playwright 1.61.0.
• gflow-cli 0.72.0, installed from PyPI in a local virtual environment; previously 0.71.1.
• Engine: Playwright with real Chrome, persistent default profile.
• Migrated host: flow.google.com.
• Account normally uses zh-CN. The final failed run resolved locale as en after logging account_locale_lang_unchanged with reason Error; earlier runs resolved zh.
• Two local PNG references, model omni-flash, 16:9, 8 seconds, count 1.
• Invoked by an OpenMontage adapter using a subprocess argument list, not a manually executed shell command.

Redacted equivalent invocation (prompt and paths are placeholders, not a separately tested minimal reproducer):

gflow video r2v "<single-shot two-character comedy prompt, image reference tags, timed beats and Mandarin dialogue>" --aspect 16:9 --model omni-flash --duration 8 --count 1 --profile default --output "<output.mp4>" --json --ref "<character-a.png>" --ref "<character-b.png>" --project "<existing-project-id>"

Recovery steps already performed

1. Updated 0.71.1 to 0.72.0. On Windows, self-update hit WinError 32 on its running gflow.exe; installing 0.72.0 through the virtual environment's Python repaired the installation.
2. gflow doctor passed all 10 checks.
3. Refreshed login with gflow auth login --profile default --browser chrome; both in-context and on-disk verification succeeded.
4. gflow credits user --profile default --json then returned HTTP 200 and authenticated=true. An earlier credits 401 was resolved by this login refresh.
5. Retried the unchanged R2V request once. It still timed out after editor_ready.
6. Stopped generation retries.

Observed event sequence (UTC, 2026-09-10)

13:00:54.922 browser.engine_selected: playwright
13:00:55.436 client.persistent_context_launch: channel=chrome
13:00:56.076 client.context_cookie_state: Flow session present, not expired
13:00:58.450 client.account_locale_lang_unchanged: lang=en, reason=Error
13:00:58.455 migrated.dispatch: mode=r2v
13:00:58.455 migrated.navigate: flow.google.com/project/<redacted>
13:01:03.560 migrated.editor_ready
13:01:08.599 incident.capture_started
13:01:09.061 incident.capture_completed
13:01:09.095 error_unhandled: exception_class=TimeoutError

No settings_applied or reference-upload event appeared in the captured failure log. This suggests an early settings-phase failure, but is not proof of a specific selector or an overlay.

Incident: 71ec019a-5e1a-4b6c-9be0-9bff0c177859-e38ffed5ae

• message_hash: 736724283642cc6f43ef43b3cfef05b3c3bd8e558b5323171d842ddc4b3189d8
• stack_hash: e175849b68a4a6fbd17cf5e9c82edcd56a7493cd2fcacda6e374664616aea652
• Report: unexpected TimeoutError, exit code 1, retryable=false, phase video_generation.
• network.json: generation_requests: [], 100 records.
• Credit balance immediately before and after: 433 -> 433; observed spend 0.
• No MP4 created.

Diagnostic limitation

The incident ui.json contains all-zero tag counts, no ligatures, and URL/title category other. In light of #722, this snapshot must not be taken as proof the editor was blank at failure time. The log explicitly reported editor_ready first. No usable pre-teardown screenshot or failing-locator traceback is available in the captured adapter output.

Expected behavior / investigation request

The supported local-reference R2V path should apply the requested settings and attach both references, or fail before submitting with a diagnostic naming the failed action. Please inspect the settings-pane path after editor_ready and preserve the failing locator/actionability trace before page teardown. Please also check whether the locale-settle error is relevant; that remains unverified.

This report includes only manually selected, redacted diagnostic fields. Account email, cookies/tokens, private project ID, local paths, source images, and the full creative prompt are omitted.

[ffroliva]

Assessment: CONFIRMED-BUG. Thank you for the report — the timestamps in it are what settled this, so the detail was not wasted.

The failing line

_open_pane makes exactly two calls between migrated.editor_ready and the next log line:

Call	Guarded?	On failure
trigger.wait_for(state="visible", timeout=5000)	✅	UiSelectorDriftError, exit 23, names the anchor
trigger.click(timeout=5000)	❌	raw TimeoutError, exit 1, names nothing

You got a bare TimeoutError, so it was the click — and your own numbers confirm it: editor_ready 13:01:03.560 → incident.capture_started 13:01:08.599 = 5.039 s, which is a wait_for returning immediately plus a 5000 ms click timeout. There is no other unguarded 5000 ms call in that window. The control was visible; it just never became clickable.

For context on how long this has been latent: #752 finding #7 predicted this exact symptom at this exact function before you filed. Its count()→visibility half was fixed; the click half was not.

Your locale question — measured, and the answer is no

You asked whether account_locale_lang_unchanged … reason=Error is relevant. I ran a $0 probe on a migrated-host account three times today. All three reproduced it:

client.account_locale_lang_unchanged  lang=en  reason=TimeoutError  waited_ms=4000.0

…and the click landed normally every time (65–130 ms). So a failed locale settle is not sufficient to cause this. It is real and separately tracked as #643. Consistent with the design: the anchor is .settings-trigger-button, a structural selector, so no locale can hide it.

What I could not determine

What actually blocked your click. Two candidates were live and neither could be measured:

• Flow's announcement overlay (Changelog announcement modal blocks every UI action; make dismissal a precondition, not a per-boundary call #593) — that was measured on labs.google, never on the migrated host. My probe read body{pointer-events} as auto in 159 of 159 samples, including while Flow's own settings pane was open. Angular CDK blocks with a .cdk-overlay-backdrop element rather than muting the body, so the labs mechanism may simply not apply here.
• A mid-run agent-mode flip (Follow-up on #751: code review found 13 issues in the agent-mode fix, 2 of them real defects in the tests #752's cause), which touches neither the body property nor the hit test.

0 of 3 is unmeasured, not disproven — your machine saw something mine did not, and I would rather say so than guess. Building a fix around either guess would have produced a confidently wrong message; #770 is a live example of what that costs.

What the fix does

Exactly what you asked for — "fail before submitting with a diagnostic naming the failed action" and "preserve the failing locator". On a click timeout the driver now reads Playwright's four actionability conditions back and reports the ones that fired: the agent chip, hidden/disabled/not-rendered, page-wide pointer-events, and a hit test naming what is on top. When every reading is healthy it says so, which rules out three conditions and points at the fourth (stable — the control still moving or re-rendering). Exit 23 instead of 1.

Two notes for your setup specifically:

• Your adapter may have been seeing less than you think. With --json and no debug flag, an unhandled exception emits no detail and no exception class on stdout — the exception_class=TimeoutError you quoted comes from the stderr structured log. If the adapter captures only stdout, it got nothing diagnostic. After this change the failure is a typed error, so --json carries the full problem details.
• If you drive this over MCP rather than the CLI, the queued path was worse still: a non-typed exception reached the caller as "detail": "sha256:…". That is fixed by the same change.

Fix in #778 (route-intercepted e2e, six scenarios, real browser, $0). The spike and its raw numbers are in docs/superpowers/spikes/2026-09-10-migrated-click-blocked.md.

If it recurs after this ships, the new message will name the cause — please paste it, and that will close the gap I could not measure from here.

[ffroliva]

Released in v0.73.0 — please give it a try when you get a chance.

gflow update            # or: pip install -U gflow-cli / uv tool upgrade gflow-cli
gflow --version         # expect 0.73.0

Then re-run the same video r2v command that failed.

What to expect

If it works — nothing to report, and thank you for the timestamps; they are what localised this.

If it fails again, the failure should now look completely different. Instead of a bare TimeoutError with exit 1, you should get exit 23 and a message naming the control and the condition that actually failed — one of:

Message	Meaning
… the account is in Flow's agent mode	turn the Agent chip off in a browser, re-run
… it is covered by <tag>.<class>	something is stacked over the control; the class names it
… the page is accepting no pointer events at all	an overlay has the whole app blocked
… it carries a bare hidden attribute / it is disabled	present but unusable
… it was visible, enabled and hit-testable … most likely still moving	nothing readable was wrong — see below
… it could not be read back	the page changed under the diagnosis

Please paste whichever one you get. That is the measurement I could not take from here — the condition never reproduced on any profile I hold (0/3), so your machine is currently the only place it exists.

The fifth row is worth flagging: it means the driver looked and found nothing wrong, which points at Playwright's stability check — the control still moving or re-rendering. It is a real answer, not a fallback, and it would be genuinely useful to see.

Two other things from your report

• The locale error is not the cause. I reproduced account_locale_lang_unchanged … reason=Error on 3 of 3 runs while the click landed normally. It is real and tracked as bug: locale resolution is blind on flow.google.com and DEMOTES a learned locale (measured en + pt-BR) #643, but it is not what broke your run.
• Your adapter may have been seeing less than you think. With --json and no debug flag, an unhandled exception emitted no detail and no exception class on stdout — the exception_class=TimeoutError you quoted came from the stderr structured log. Now that the failure is a typed error, --json carries the full problem details, so a stdout-only reader will finally see something.

If you drive this through MCP rather than the CLI, that path was worse still — a non-typed exception reached the caller as "detail": "sha256:…". Same fix covers it.