Luma Ray 3.2 image-to-video rejects "10s" duration despite OpenAPI listing it

gistfile1.txt

Endpoint affected: luma/agent/ray/v3.2/image-to-video
  
  Severity: Schema-vs-runtime mismatch. Customers selecting 10s
  clips with a start frame get a generic "Invalid input" error
  and no actionable feedback.
  
  Reproduction (curl, ~10 seconds):
  
  # This fails with HTTP 422 / "Invalid input" / loc:["body"] / 
  input_value_error
  curl -X POST
  "https://queue.fal.run/luma/agent/ray/v3.2/image-to-video" \
    -H "Authorization: Key $FAL_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "prompt": "a person waves",
      "image_url": "https://storage.googleapis.com/falserverless/
  gallery/example_inputs_liuyifei.png",
      "duration": "10s"
    }'

  Note: this uses your own gallery example image, not a customer
  image. We've reproduced the same failure with multiple images
  on multiple S3/CDN hosts — image source is irrelevant.
  
  Expected behavior:

  The OpenAPI schema at https://fal.ai/api/openapi/queue/openapi.
  json?endpoint_id=luma/agent/ray/v3.2/image-to-video declares:

  "duration": { "enum": ["5s", "10s"], "default": "5s", "title":
  "Duration" }

  So "10s" should be accepted, or the schema should reflect that
  i2v is 5s-only.

  Actual behavior:

  Every "duration": "10s" request fails after queueing with:
  
  {
    "detail": [{
      "loc": ["body"],
      "msg": "Invalid input",
      "type": "input_value_error",
      "url": "https://docs.fal.ai/errors#input_value_error",
      "input": { /* echo of all submitted fields */ }
    }]
  }
  
  Failure mode is fast (~1s "inference_time") and consistent —
  confirmed across:
  
  - Customer image (3:4 portrait, 880×1168 PNG, public CloudFront
   URL): fails
  - fal's own stock example image: fails
  - All aspect ratios (16:9, 3:4, default): fail
  - All resolutions (540p, 720p, 1080p, default): fail
  
  Sample failing request IDs from our account:
  
  - 019eb1d0-a9b5-7922-a278-283c9b09e82a — 10s
  default-aspect/default-res
  - 019eb1d0-abe5-7b60-bd01-e0d5bbb1fda7 — 10s 3:4 720p
  - 019eb1d1-458c-7c03-9b07-250e17e26979 — 10s with fal's stock
  liuyifei.png
  
  Control — text-to-video accepts 10s normally:

  # This succeeds and produces a 10s clip
  curl -X POST
  "https://queue.fal.run/luma/agent/ray/v3.2/text-to-video" \
    -H "Authorization: Key $FAL_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{"prompt": "a fox running", "duration": "10s"}'

  So the limitation is specific to the image-to-video endpoint,
  not Ray 3.2 in general.
  
  Control — 5s on i2v works at every resolution/aspect 
  combination:
  
  We bisected with 5s + every other combination (3 resolutions ×
  5 aspect ratios) — all 200/COMPLETED with valid output.
  
  Request: Either

  1. Enable 10s on the i2v endpoint (preferred — matches schema
  and text-to-video parity), or
  2. Remove "10s" from the i2v duration enum in the OpenAPI so
  client SDKs and our UI can hide it correctly, or
  3. Return a specific, actionable error message (e.g. "10s 
  duration is not supported on Ray 3.2 image-to-video; use 
  text-to-video for longer clips") so we can surface it to end
  users instead of a generic "Invalid input".
  
  We've shipped a client-side workaround (UI clamps duration to
  5s when a start frame is attached for this model), but we'd
  like to remove it once the backend is consistent with the
  schema.

  Happy to provide additional request IDs or our API key for
  verification — let us know.