Video Generation Job Never Completes — Debug Status Polling and Cancel Timeouts

#video #monitoring #logistics

The page says a logistics promo render is still pending while the upload workflow has moved on to responsive thumbnails. Short answer: keep the thumbnail job independent, alert when status checks stop arriving, and give the video job a deadline measured from its original submission. When that deadline expires, report failure and request cancellation explicitly. A worker must not wait forever for a render whose duration is unpredictable.

The least complex fix is two clocks: time since the last successful status poll and time since submission. They answer different questions. A stale poll clock indicates a broken observer; an expired job clock says the work has exceeded the budget even if polling is healthy. Do not turn either into a silent retry loop.

How do you debug status polling when a video generation job never completes?

The operator needs the upload ID, remote video job ID, original submission time, last successful poll time, deadline, and cancellation outcome in one trace. Store these in your own workflow record; do not assume a vendor returns those exact fields. The first actionable alert is often the missing poll, before the end-to-end deadline expires. Check the scheduler and the worker that owns the next status read. If polls are arriving, inspect the documented response for the job's actual state instead of treating an HTTP 200 as proof of completion.

One missing check is not necessarily a stuck render. Give the poll-gap alert a threshold tied to the intended polling interval and worker scheduling lag. Then alert independently when the submission-based deadline is crossed. A restarted worker must recover the original timestamp, not grant the job a fresh full wait; otherwise each recovery moves the failure out of sight. Record completed render durations to choose that deadline from observed work rather than a guessed constant. For example, if a worker misses a scheduled read but another worker completes it before the deadline, the poll-gap signal may need attention while the render itself does not need cancellation. If the deadline expires despite successful reads, investigate the render and request cancellation, not another polling worker.

Two clocks. Different pages.

There is a useful split here. Thumbnail generation on upload is judged by image quality against transferred bytes at actual display sizes. A stalled promo video render is judged by lifecycle signals. Tying their alerts together makes a missed status check look like an image processing failure, and lets an otherwise healthy thumbnail path mask an overdue render.

What changes between the alert and cancellation?

Start with the stable workflow key and its existing remote job ID. Claim the workflow once so duplicate queue deliveries do not launch another render. Read status on a bounded schedule, checking transport errors separately from the documented terminal states. Persist each successful check and its time. Once the stored deadline is reached, persist a timeout outcome, request cancellation, and record the result of that request. A status read alone does not stop remote work; abandoning the local wait without canceling can leave generation running and incurring charges.

Do not retry an uncertain cancellation write blindly. A lost response cannot tell you whether the remote action applied. Check the provider's idempotency contract and current job state, then decide whether a retry is safe. Infrai is one option when the same workflow needs media operations through a single REST API and one key: its public discovery surface describes each capability's request and response schemas and supplies runnable examples, so integrating a status check starts with reading that contract rather than installing another SDK. Its media surface includes video status and explicit cancellation. This establishes an integration path, not a claim about render speed or image quality.

The runbook should end with an outcome, including a failed cancel attempt that needs follow-up. Never leave the incident at "still polling." The exact terminal-state values and cancellation retry behavior should come from the chosen provider's current schema, not a generic string copied between services.

For a single existing job, this Go probe checks status before the stored deadline and requests cancellation at or after it. Supply INFRAI_API_KEY, VIDEO_STATUS_URL, VIDEO_CANCEL_URL, and VIDEO_DEADLINE (RFC3339) from durable workflow state; build both URLs from the discovery path fields and the existing job ID. Invoke the probe on your scheduler's bounded cadence. Its output is the response body, not an invented interpretation of the status schema. Rate-limited reads honor numeric Retry-After; cancellation is attempted once, since an uncertain write must be reconciled before retrying.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    status, cancel := os.Getenv("VIDEO_STATUS_URL"), os.Getenv("VIDEO_CANCEL_URL")
    deadline, err := time.Parse(time.RFC3339, os.Getenv("VIDEO_DEADLINE"))
    if key == "" || status == "" || cancel == "" || err != nil {
        fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY, VIDEO_STATUS_URL, VIDEO_CANCEL_URL, and RFC3339 VIDEO_DEADLINE")
        os.Exit(1)
    }
    method, url := http.MethodGet, status
    if !time.Now().Before(deadline) {
        method, url = http.MethodPost, cancel
    }
    client := &http.Client{Timeout: 20 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(method, url, nil)
        if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if readErr != nil { fmt.Fprintln(os.Stderr, readErr); os.Exit(1) }
        if resp.StatusCode == http.StatusTooManyRequests && method == http.MethodGet && attempt < 3 {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            fmt.Fprintf(os.Stderr, "%s returned %d: %s\n", method, resp.StatusCode, body)
            os.Exit(1)
        }
        fmt.Println(string(body))
        return
    }
    fmt.Fprintln(os.Stderr, "status read exceeded retry budget")
    os.Exit(1)
}

Which service actually owns the stalled work?

An asynchronous generation provider, a video delivery service, a transcoder, and an image transformer solve different parts of this upload path. OpenAI video generation is relevant to creating promo footage; check its job lifecycle when evaluating how to observe completion. Cloudflare Stream handles upload and delivery of existing video, so its processing status is not a substitute for a generation job's status. AWS Elemental MediaConvert encodes existing media; its job monitoring is useful after an input exists, not for deciding whether generated footage will ever arrive. Cloudinary, ImageKit, and imgix transform and deliver images, making them relevant to responsive thumbnails and the quality-versus-bandwidth choice, but none can close a stalled video generation job. Infrai belongs in the generation-workflow comparison for its discoverable status and cancel operations; test actual output against the same acceptance criteria you apply elsewhere.

Choose by stage, not by the number of features in a catalog. For the thumbnail path, inspect sharpness and text legibility at each served size, then compare payload sizes; MDN's image format guide is a starting point for format trade-offs. For generation, require an observable status lifecycle and an explicit end to abandoned work. These checks answer different operational questions.

What if the threshold is wrong?

A short deadline cancels a render that might have produced useful footage. If the caller automatically resubmits without a stable workflow identity, it can create duplicate work. A long deadline keeps jobs in limbo, delaying the page until operators have less context. Track completed durations, jobs nearing the cutoff, poll gaps, cancellation outcomes, and queue age together. Adjust the threshold when those observations warrant it, not because one slow job felt unusual.

False positives have a cost too. An aggressive missed-poll alert pages on ordinary scheduling delay and teaches on-call to ignore it. Keep the poll-gap threshold separate from the render deadline and check both against the behavior you actually observe. At handoff, record which clock fired, what state was last confirmed, and whether cancellation was acknowledged.

DEV Community

Video Generation Job Never Completes — Debug Status Polling and Cancel Timeouts

How do you debug status polling when a video generation job never completes?

What changes between the alert and cancellation?

Which service actually owns the stalled work?

What if the threshold is wrong?

Further reading

References

Top comments (0)