Omni job status names: pending vs queued, cancelled vs canceled

The same Gemini Omni Flash job shows two status vocabularies on Sume. GET /v1/videos/{id} returns pending, in_progress, completed, failed and cancelled. The job API returns queued, processing, completed, failed and canceled, one l in the last. Code that compares strings against the wrong set will poll forever.

Mapping

A normalizer

Fold both vocabularies into three states before your loop sees them.

const TERMINAL = { completed: "done", failed: "error", cancelled: "error", canceled: "error" };
const WAITING = new Set(["pending", "queued", "in_progress", "processing"]);

export function state(status) {
  if (status in TERMINAL) return TERMINAL[status];
  if (WAITING.has(status)) return "wait";
  throw new Error("unknown status " + status);
}

Why it matters on Omni

A job stuck in a wait state is not free: a 10 second 1080p Omni clip holds $1.875 until it ends. Treat an unknown status as an error, not as "keep waiting".

Webhooks send terminal events only (completed, failed, canceled), with no progress deliveries, so keep a poll as backup for a missed delivery.

Poll on booleans when you can

On the job endpoints, GET /v1/jobs/{id}/status also carries terminal and result_ready booleans. Polling on those avoids string comparison entirely: stop when terminal is true, and fetch /v1/jobs/{id}/result when result_ready is true. When next_poll_after_seconds is present, obey it; otherwise back off between polls.