Does Closing the Page Stop a Queued Video Job?

Closing a page, terminating a script, or pressing a stop button does not necessarily cancel video generation. The client may simply stop waiting. Once a server accepts a job, cancellation depends on its API and the job's state when that request arrives.

On November 12, 2026, we read MiniMax V2's query reference and cancel-or-delete reference, then compared the Nbility H3 documentation. We did not create, cancel, or download an actual video or verify any refund.

Track four separate actions

A returned task ID establishes acceptance of a job. Completion and local storage are later steps.

Action	What changes
Stop polling or close the page	The client stops querying
Cancel a task	The server attempts to stop work that remains cancellable
Delete a task record	A record is removed according to the API contract
Download the result	Existing generated media is copied into your storage

A local timeout can occur while the model continues processing. Preserve the ID and query that task later. “I stopped waiting” does not establish “the server never received it.” Likewise, task success does not establish that your media library holds the file.

The image recovery guide also separates submission, querying, and downloads. This article adds video cancellation and deletion semantics without combining their protocols.

Official cancellation depends on the current server state

MiniMax V2 calls DELETE /v2/video_generation/{task_id} “Cancel or Delete Task.” Its action depends on the current server state:

Official V2 state	DELETE behavior
queued	Cancel; action: cancelled. The documentation says processing has not begun and there is no charge
running	Cancellation is not allowed; returns an error
succeeded or failed	Delete the record; action: deleted
cancelled	Not allowed; returns an error

A recently displayed queued state does not guarantee cancellation. Query and cancellation are separate requests, and processing can begin between them. Use the actual cancellation response. If it fails or its outcome is unknown, inspect the existing job before creating another.

Deleting a successful record does not mean undoing generation, obtaining a refund, or proving every media copy was erased. Data-erasure requirements need separate service terms or support verification.

Keep official and gateway protocols separate

MiniMax V2 queries GET /v2/query/video_generation/{task_id}, reports success as succeeded, and returns media in task.content.url. Nbility H3 queries GET /v1/videos/{task_id}, reports completed, and returns url. Legacy MiniMax documentation also uses Success and file_id; it needs another parser.

Protocol checked	Success state	Result location
MiniMax V2	succeeded	task.content.url
Nbility H3	completed	url

Nbility documents creation, querying, downloading, and media uploads. We did not verify an equivalent cancellation or deletion endpoint there. Do not copy the official V2 DELETE path onto the Nbility host or send a Nbility key to the official host.

For an existing Nbility job, this read-only query saves its response privately. We checked Shell syntax but did not send the request. Supply the key through private environment configuration:

umask 077
export VIDEO_TASK_ID='YOUR_EXISTING_TASK_ID'
curl --fail-with-body --silent --show-error \
  -H "Authorization: Bearer $NBILITY_API_KEY" \
  "https://api.nbility.ai/v1/videos/$VIDEO_TASK_ID" \
  --output video-task.json

Nbility's documentation suggests polling every five to ten seconds. Set an overall waiting limit and respect rate limits and backoff. Reaching a client limit means “stopped waiting, result unresolved,” not a server failed state.

Recover identity before retrying an uncertain submission

Before creation, assign a local operation ID and save the request summary and send time. Persist the server ID immediately after receiving it. Track at least:

Local operation ID: identity of this creative operation
Provider and protocol version: how to query it later
Server task ID: identity returned after acceptance
Task state: unknown, waiting, running, or terminal
File state: not saved, downloading, or verified
Notification state: whether completion reached the business system

These are suggested application records, not a complete Nbility data structure or a POST idempotency guarantee. Nbility's H3 documentation does not promise that a client Idempotency-Key deduplicates independent creation requests. Identical prompts are not server task identities either.

If a timeout occurs before receiving an ID, retain timestamps and available request identifiers and inspect the provider's records or contact support. If the outcome cannot be established, explicitly decide whether to accept another creation. The retry and failover article explains why automatic retries across layers can amplify this problem.

Make downloads and notifications recoverable

MiniMax V2 currently permits queries for tasks from the last seven days and says result URLs are time-limited. That window is not Nbility's retention policy or a guarantee that a video URL lasts seven days. Save your own copy promptly. Recover a failed download without submitting another generation.

A result URL may use an independent media host. Do not attach the model API key by default. Download to a temporary file, then check content type, size, and media decoding before marking it saved. HTTP 200 and an .mp4 extension are insufficient.

For completion messages or external writes, retain operation and task identifiers and use a deduplication mechanism at the destination. A local “sent” boolean cannot by itself handle a crash after a successful send. Query the destination record or use its supported idempotency identifier when recovering; see n8n retries and external effects.

Before starting the next clip, establish the previous job's identity, actual terminal state, and saved file. The Gemini Omni workflow covers creative iteration. When changing models or protocols, keep each service's query, cancellation, and storage rules intact.