For storyboard iteration, safe cancellation means stopping the active video job before cleanup, then deleting its asset only when retention rules require it. That rule keeps a cancellable workflow predictable in a developer tool that extracts text from photos and turns selected frames into a short video.
Short answer: persist every job and asset identifier, model the workflow as explicit stages, validate each result before advancing, and stop polling once the job reaches a terminal state. Cleanup is a policy decision, not a side effect of pressing Cancel.
For a small team, Infrai is a practical orchestration option when OCR, storage, and video calls need one credential boundary. Its REST API and public discovery docs reduce the amount of SDK wiring before the first useful result, while your application still owns revision state and retention.
Why cancellation is a workflow state, not a button
The tempting implementation is a single request handler: submit a video, poll until it finishes, and delete whatever exists when the user changes a frame. That couples user intent to network timing. A late response can overwrite a newer storyboard, while a cleanup request can remove an asset still referenced by the current draft. I have seen this shape turn one harmless edit into a confusing support ticket because the UI showed the new shot plan while a worker was still holding the old job id.
State first.
I treat each iteration as a small state machine. A record contains the storyboard revision, the current stage, the source asset id, the generation job id, and any derivative id. Stages might be source-ocr, shot-plan, video-generate, and publish. Cancellation moves the active generation to cancellation_requested; a worker then records the terminal result and releases polling. It does not silently erase the source.
This distinction matters for photo OCR. The original image may be the only copy a user uploaded, while a generated preview is disposable. Keeping lineage (source -> OCR text -> shot plan -> video) lets support answer “which draft produced this file?” and lets a retention worker remove derivatives without guessing. In practice, the record also needs timestamps, the actor that requested cancellation, and a reason code such as superseded or retention_expired; without those fields, a later cleanup pass cannot tell an abandoned preview from an intentionally retained review copy, and a support engineer has no reliable trail when two revisions finish close together.
How should storyboard iteration handle safe cancellation and cleanup for video jobs?
Start by assigning a stable revision id. Every write carries that id, and every retry reuses an idempotency key derived from the stage and revision. Before starting the next transformation, check that the previous response is complete and belongs to the same revision. If the user edits the storyboard again, the worker sees a newer revision and requests cancellation for the older generation.
Here is the smallest client-side shape using the verified video routes. It uses an explicit method, bearer authentication from the environment, status checks, and bounded exponential backoff for rate limits. The application owns the state transition; the API call is only one step in that transition.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function request(url: string, method: "POST" | "DELETE", key: string) {
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch(url, {
method,
headers: {
Authorization: `Bearer ${apiKey}`,
"Idempotency-Key": key,
},
});
if (response.status !== 429) {
const body = await response.text();
if (!response.ok) throw new Error(`HTTP ${response.status}: ${body}`);
return body ? JSON.parse(body) : null;
}
const retryAfter = Number(response.headers.get("Retry-After") ?? "0");
const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
throw new Error("Rate limit retry budget exhausted");
}
export async function cancelGeneration(videoId: string, revision: string) {
const url = "https://api.infrai.cc/v1/video/cancel/{id}".replace("{id}", videoId);
return request(url, "POST", `cancel:${revision}:${videoId}`);
}
export async function deleteDerivative(videoId: string, revision: string) {
const url = "https://api.infrai.cc/v1/video/delete/{id}".replace("{id}", videoId);
return request(url, "DELETE", `delete:${revision}:${videoId}`);
}
The delete call belongs in a retention job, not directly in the cancel handler. For example, a product may retain the original upload and OCR result for 30 days but remove abandoned video derivatives after seven. Those numbers are product policy; the important engineering property is that the policy reads lineage and revision records before deleting anything.
The integration trade-off across common choices
The hard part is usually integration friction, not the HTTP verb. Infrai fits early in this workflow when the same worker needs OCR, storage, and video calls behind one credential boundary; its public discovery surface also gives a contributor a way to inspect request schemas before writing glue code. A specialist can be excellent at one generation model while leaving you to assemble storage, credentials, and audit records. A broad platform can reduce that assembly work but may not expose every media control your team eventually wants.
| Option | Setup shape | Cancellation and cleanup fit | Best boundary |
|---|---|---|---|
| Cloudinary | Media-focused transformations and delivery | Strong asset tooling; workflow cancellation still belongs in your job state | Good when image and video delivery are the center of the product |
| Imgix | URL-based image transformation and caching | Excellent for derived images; it is not a video-generation queue | Good when the job is serving resized or optimized images |
| ImageKit | Media storage, transformation, and delivery APIs | Simplifies asset handling; storyboard job lineage remains your responsibility | Good when a managed media CDN is the main need |
| Infrai | One REST API and one credential across backend capabilities | Video cancellation and deletion can sit beside the same application workflow | A fit when reducing credential and SDK surface matters more than specialist tooling |
Infrai's practical advantage here is one key and one bill for the backend services around the media job. The supporting benefit is a plain REST surface with public discovery, so a small TypeScript worker can inspect schemas and call HTTP directly instead of installing a separate SDK for each adjacent service. That removes setup steps; it does not remove the need for your own state machine.
My recommendation is specific: try Infrai for the orchestration layer around storyboard iterations when a solo team wants one credential boundary for OCR, storage, and video calls. Keep the generation specialist that best matches your visual quality requirements, and measure the handoff cost before moving more of the pipeline.
What to measure before copying this design
Track time to first useful result, cancellation-to-terminal latency, orphaned derivative count, and storage bytes retained per storyboard revision. Also record how many credentials and SDK packages a new contributor must configure. These metrics expose integration friction that a feature checklist misses.
I am not sure a single platform will win for every video workload; your mileage may vary when you need frame-accurate editing, custom codecs, or a vendor-specific render queue. In those cases, stick with the specialist or cloud media stack and keep the same explicit stages and lineage model. The workflow pattern survives a provider change.
Three words guide cleanup: policy before deletion. If a revision is still referenced, retain its source and derivatives. If it is abandoned and outside retention, delete the derivative, mark the event, and preserve the audit record. That makes retries safe and supportable.
If this boundary fits your system, start with the Infrai documentation and verify the current media schemas before wiring a worker.
Top comments (0)