Skip to content

video i2v: --duration is silently ignored when the duration tab probe fails (requested 4s, got 8s) #288

Closed

Description

@ffroliva

Observed (0.31.0, live run 2026-07-11, chalkboard i2v pilot)

gflow video i2v --duration 4 on the Frames submode (portrait, veo-lite, denon82 profile) produced an 8-second clip. The duration tab selector never matched and the failure was demoted to warnings:

{"probe": "duration_tab", "event": "ui_automation_video.selector_probe_failed", "level": "warning"}
{"seconds": 4, "event": "ui_automation_video.duration_not_set", "level": "warning"}

Generation then proceeded with Flow's default (8s). The JSON result reports success with no indication the requested duration was dropped — the only evidence is ffprobe on the output file.

Why this matters

Duration is a contract parameter: downstream timeline math (scene slots in a Remotion cut) sizes freeze-holds and cut points from the requested value. A silent 4→8 substitution corrupts the edit plan without any failure signal. Same design principle as the #281 wrong-media fixes: when the UI automation cannot honor an explicit user parameter, fail fast (or at minimum surface it in the result payload), don't warn-and-continue.

Suggested fix

  1. Investigate the duration_tab selector against Flow's current Frames-submode DOM (may be another agentic/classic cohort split or a UI update — compare gflow image t2i fails finding Flow aspect-ratio mode switch trigger #183's aspect-switch probe rot).
  2. Policy: explicit --duration + probe failure → hard error (new typed error, non-zero exit) unless a --best-effort style flag is passed. If warn-and-continue is kept for any path, the final JSON result must carry requested_duration vs effective_duration so callers can detect the substitution programmatically.

Repro context

  • 3/3 i2v generations in the run showed the same probe failure; both completed clips measured 8.000s via ffprobe (one requested 4s).
  • Full structured logs available (correlation ids 17c1d945, 477bc557, 8ad4b3a1).

Activity

  1. added this to the 0.32.0 milestone on Jul 11, 2026
  2. ffroliva commented on Jul 11, 2026

    @ffroliva
    OwnerAuthor

    Fix in flight on draft PR #289: an explicit --duration whose duration_tab probe misses now raises UiSelectorDriftError (exit 23) with a debug_no_duration_tab.png viewport screenshot, instead of silently generating at Flow's default. Omitting --duration is unchanged.

    The selector investigation itself stays open here. Leading hypothesis from the council review: locale-sensitive tab labels. The duration tabs are matched by visible text ([role='tab']:text-is('4s')) with no locale-invariant fallback — unlike the aspect tabs, which lead with crop_* icon ligatures, and this codebase has prior text-match rot on non-English accounts (upload-media, add-to-prompt tri-lingual fallback). A localized label like 4 s/4 с would miss text-is('4s') exactly as observed 3/3. When someone reproduces with a headed browser: please attach the debug screenshot and note the account locale of the profile (denon82) — if the label is localized, the fix is a locale-invariant anchor for the duration tab group, not a text-match patch.

  3. ffroliva commented on Jul 11, 2026

    @ffroliva
    OwnerAuthor

    Live investigation result (2026-07-11, denon82, credit-free): the duration_tab probe misses because the duration control is absent from this cohort's Frames-submode settings popover — not a renamed/localized tab.

    Evidence: PR #289's fail-fast fired live (--duration 4 → exit 23, aborted pre-submit, saving the 10-credit generation) and captured debug_no_duration_tab.png. The popover shows, in full: Imagem/Vídeo mode tabs → Frames/Elementos sub-mode → aspect 9:16/16:9 → count 1x/x2/x3/x4 → model dropdown (Veo 3.1 - Lite) → 'A geração vai usar 10 créditos'. No duration row.

    The locale hypothesis from the council review is refuted: the UI renders in Portuguese (labs.google/fx/pt/... — the profile's Chrome locale wins, as documented on #56) and the sibling count tabs (1x/x2, same text-match strategy) match fine.

    Open question that remains on this issue: did Flow remove clip-length selection for this cohort/model, or move it (e.g. model-dependent, or post-generation)? Until answered, --duration cannot be honored on affected cohorts and #289's typed error is the correct permanent behavior there, with 'omit --duration' as the workaround.

    Also observed while investigating (same session): project f6caf027 opens in the full-page media-library UI (#174 shape) with an 'Agente' composer pill, where even the mode_switch_trigger probe fails — fresh projects still get the classic composer and work. Worth a separate eye when tackling #174.

  4. added a commit that references this issue on Jul 11, 2026
  5. ffroliva commented on Jul 11, 2026

    @ffroliva
    OwnerAuthor

    Shipped in PR #289 (merged to develop, releasing in v0.32.0) and live-verified: --duration 4 on the affected cohort now aborts pre-submit with UiSelectorDriftError (exit 23) + debug screenshot instead of silently producing an 8s clip — the run saved the 10-credit generation.

    Root cause confirmed with screenshot evidence (comment above): the duration control is absent from this cohort's Frames-submode settings popover — not selector rot, nothing to patch. The 'removed vs moved by Flow' question is tracked in KNOWN_ISSUES ('Video duration tab probe misses…'); if Flow re-introduces the control, the existing selector cascade should match it again and the fail-fast simply stops firing. Closing as the gflow-side behavior is complete and correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions