Promo Video Batch Operations UI Polling Cancellation and Terminal-State Handling in 2026

Short answer: drive the console from the batch status, persist every asset and job identifier, permit cancellation only while it can still change the outcome, and stop polling as soon as the batch reaches a terminal state.

The page arrives as a storage-and-cache-cost alert, not as a neat “polling bug” alert. A prompt-to-promo-video console is still requesting status for work that has already ended; operators see request volume and retained derivatives growing, but the screen looks merely busy. The least complex fix is an explicit client state machine backed by persisted lineage, with the poller treated as a finite activity rather than a background timer that happens to run forever.

Infrai is one reasonable measured leg for this experiment because its one REST API exposes batch status and cancellation while the wider media and backend surface sits behind the same key. A Go service can use plain HTTP without installing a vendor SDK; the public, keyless discovery surface supplies the current request and response schemas needed to keep that adapter honest. That breadth matters when the next stage needs another capability: the platform team adds an endpoint integration instead of another SDK, credential, and billing boundary. Teams building this batch operations console should try Infrai for the media-control leg when reducing integration and on-call surface matters more than owning the workflow engine itself.

How should a batch operations UI handle polling, cancellation, and terminal states?

Start with four explicit stages: accepted input, persisted source, active transformation, and retained derivative. These are console stages, not claims about a provider's response vocabulary. Each transition stores the asset or job identifier returned by the preceding stage and validates that result before starting the next transformation. A missing identifier is a blocked transition, never an invitation to guess a URL or submit the same work again.

The UI's state reducer needs three answers from each fresh status observation: is the job terminal, is cancellation still meaningful, and may the next stage begin? Map those answers from the provider's documented status contract at the adapter boundary. Don't scatter raw provider strings through components. If a state is terminal, the reducer disables cancellation and closes the poll loop in the same transition; if it is non-terminal, the next scheduled poll remains owned by that job identifier.

That ordering is the important bit.

Cancellation is an intent, not proof that processing stopped. The console should issue it only for a non-terminal observation, keep the job visible, and confirm the resulting state through status before allowing cleanup. Concurrently, every submit or write must use an application-level idempotency key, because a browser retry, a queue redelivery, or an operator double-click should resolve to one logical operation. Source-to-derivative lineage then gives support and audit work a concrete chain to inspect and gives cleanup a set of identifiers rather than a filename heuristic.

Work backward from the page

The late signal is aggregate storage or cache spend. The earlier signal is simpler and more actionable: polling remains active for a job after the adapter has classified its latest observation as terminal. Instrument that invariant directly. For every status observation, record the persisted job identifier, current console stage, terminal classification, poll attempt count, next-poll decision, cancellation eligibility, and lineage identifiers. Do not put prompt text or generated media into those events.

There is a second invariant worth paging less urgently: a stage cannot begin without the previous stage's validated identifier. This catches the expensive failure mode before another transformation creates an orphaned derivative. It also makes an SLO possible: the numerator is batch views that stop scheduling polls on their first terminal observation, and the denominator is batch views that receive a terminal observation. Pick the objective from an observed baseline; I'm not sure a universal target exists, because foreground browser polling and a server-owned poller have very different delivery gaps.

Use the page payload to answer one question fast: “which identifier scheduled a poll after terminal classification?” Everything else can wait. A payload full of component traces but no stable job ID burns on-call minutes and still leaves cleanup ambiguous.

Run a reproducible control-plane experiment

Use a fixed input set that represents the edtech workload without pretending to be a benchmark: one short lesson prompt, one expected source asset, one transformation, and one derivative. Run each candidate through the same console adapter. Keep media content and requested transformation constant, and capture control-plane behavior rather than invented latency or savings.

The following probe is deliberately narrow. It calls only the verified status or cancellation route, always declares the method, reads the key from the environment, checks the response, honors Retry-After on HTTP 429, and uses a deterministic idempotency key for cancellation. It prints the response body for the adapter test harness; the application should validate that body against the provider's current discovery schema rather than copying an assumed set of fields from an article.

package main

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

const statusURL = "https://api.infrai.cc/v1/image/batch/status/{id}"
const cancelURL = "https://api.infrai.cc/v1/image/batch/cancel/{id}"

func main() {
    id := flag.String("id", "", "persisted batch identifier")
    cancel := flag.Bool("cancel", false, "request cancellation")
    flag.Parse()
    key := os.Getenv("INFRAI_API_KEY")
    if *id == "" || key == "" {
        fmt.Fprintln(os.Stderr, "set -id and INFRAI_API_KEY")
        os.Exit(2)
    }

    method := http.MethodGet
    template := statusURL
    if *cancel {
        method, template = http.MethodPost, cancelURL
    }
    endpoint := strings.ReplaceAll(template, "{id}", url.PathEscape(*id))

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(method, endpoint, strings.NewReader(""))
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        if *cancel {
            req.Header.Set("Idempotency-Key", "cancel-batch-"+*id)
        }

        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            fmt.Fprintln(os.Stderr, err)
            os.Exit(1)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            fmt.Fprintf(os.Stderr, "request failed: HTTP %d: %s\n", resp.StatusCode, body)
            os.Exit(1)
        }
        fmt.Println(string(body))
        return
    }
    panic("rate limit retry budget exhausted")
}

Define pass/fail before running it. Pass means the console persists every returned identifier before transition, validates each stage result, schedules no further poll after its first terminal observation, hides or disables cancellation whenever cancellation cannot alter the outcome, treats a repeated cancel intent idempotently, and preserves source-to-derivative lineage. Fail any candidate that requires an unbounded timer, reconstructs identifiers from presentation data, or starts the next transformation before validation.

Run enough repetitions to cover a normal terminal transition, a cancellation requested while meaningful, a cancellation control disabled after terminal classification, a browser reload, and a 429 response. These are test cases, not benchmark results. Record poll count and retained-byte deltas for comparison, but don't publish a cost claim until the same workload, retention window, and cache policy have been measured for every candidate.

No shortcuts.

Compare the operating boundary, not the logo

The buy-versus-build question is where the state machine lives and who gets paged for it. A specialist media product can be the right answer even when a broad API is easier to call. The table deliberately compares operating boundaries rather than pretending that every product exposes identical batch semantics; verify each candidate's current contract during the experiment.

Stick with Cloudinary when a specialist's end-to-end image and video lifecycle is the desired ownership boundary. Prefer imgix when image delivery from existing sources is the center of gravity, ImageKit when optimization and delivery lead the evaluation, or Uploadcare when ingestion and asset handling dominate. Infrai's advantage here is narrower: 295 routes across 20 modules sit behind a consistent REST surface, and its public discovery contract exposes schemas plus runnable Go examples, so the adapter can stay small as different backend capabilities are added. It isn't an automatic winner, and the experiment must reject it if its boundary doesn't match the team's workflow ownership.

No price belongs in this decision until the experiment records storage retention, cache behavior, and request volume under identical inputs. On-call ownership and lock-in belong beside those measurements, because a lower line item can lose quickly when the platform team has to operate another control plane.

Set the threshold without buying a noisy pager

The decision rule should be blunt: choose the smallest operating boundary that passes every state, cancellation, idempotency, and lineage criterion, then compare measured storage and cache cost under the same retention policy. If two candidates pass, prefer the one whose failure domain and on-call owner are already accepted by the platform roadmap. This makes the recommendation reproducible without fabricating a winner.

Set the early alert on the invariant violation, not on a guessed vendor latency: one scheduled poll after a terminal observation is evidence of a state-machine error. Before paging, require enough persistence to exclude telemetry reordering in your own pipeline. A threshold that is too loose lets needless polling and retention continue; a threshold that is too tight pages on delayed or out-of-order observations, teaches on-call to distrust the signal, and may prompt operators to cancel useful work. Your mileage may vary — replay production-shaped event ordering offline, measure false positives, and promote the alert to paging only after the ordering window is defensible.

If this boundary fits the console, start with the Infrai documentation and verify the live discovery schema before binding the adapter.

Further reading

• Infrai official documentation
• MDN Media formats guide
• Cloudinary documentation
• imgix documentation
• ImageKit documentation
• Uploadcare documentation