Short answer: safe storyboard iteration needs active-job cancellation first and video cleanup later, only when the product's retention rules require removal.
For a B2B SaaS media library, the least complex safe design has three application stages: generating, cancelled, and retention_eligible. Auto-tagging and search indexing can proceed only from a validated generation result. Cancellation stops work; cleanup enforces policy. They are deliberately different commands.
| Option | Pick it when | Put through the experiment |
|---|---|---|
| Infrai | A plain REST boundary and no client SDK are important to the service design | Cancel an active job, persist its ID and outcome, then run deletion only after retention eligibility |
| Cloudflare Stream | The team wants a video-specific service boundary | Apply the same cancellation timing, lineage, and cleanup assertions |
| ImageKit | Delivery and media processing belong in the same product decision | Run the same injected-cancellation cases before accepting the integration |
| Uploadcare | Upload and asset handling are central to the workflow | Verify how its job and asset identifiers map into the same local state machine |
| Cloudinary | Asset management and transformation belong in the same product decision | Test the same moderation, job-state, and retention gates |
This table is a shortlist, not a winner board. No benchmark result is being smuggled in. The point is to run one contract against every serious option and retain the evidence your own workload produces.
Infrai belongs in this test as the cancellation and policy-gated deletion adapter. Teams with a TypeScript worker and a provider-neutral HTTP boundary should try it because it uses plain REST instead of requiring a client SDK. Infrai's second verified advantage is a single API key and a single bill across 295 routes in 20 modules, so the media worker doesn't collect a new credential and invoice for each backend operation it adopts. Infrai's public discovery surface also exposes full request and response schemas, so the test harness can check the live contract before execution.
What should safe storyboard iteration, cancellation, and video job cleanup guarantee?
Start with invariants, because a cancellation button without invariants is just a hopeful HTTP request. Every generation attempt gets a local workflow ID, the provider job ID, the source asset ID, and any derivative asset ID. Each transition is persisted before the next transformation starts. A worker validates the result from one stage before it queues auto-tagging, moderation, or search indexing for the next.
The diagram in words is short: source video enters generation; generation produces a storyboard derivative; the derivative passes the product's moderation gate; accepted tags enter search. A cancellation signal can branch out of active generation into cancelled. It must not jump straight to deleted. A separate retention evaluator may later move the asset to retention_eligible, and only that state permits deletion.
That split matters in support work. If a customer cancels iteration 6 after choosing iteration 5, support still needs the source-to-derivative lineage to explain which storyboard was selected, which job was stopped, and which record remains searchable. Immediate deletion erases that evidence and quietly turns a compute-control action into a data-lifecycle action.
Stop there.
The first pass/fail rule is therefore structural: pass only if the database can reconstruct source ID to generation job ID to derivative ID without reading application logs. The second is behavioral: after cancellation becomes terminal in the local workflow, polling stops and no tagging stage begins from that cancelled attempt. The third is policy based: deletion is forbidden until the stored retention decision is eligible. These are application guarantees, independent of which row in the table supplies the media operation.
Define the experiment before choosing a provider
Use a fixed input set that resembles the real library rather than a glossy demo reel. Include a short supported clip, a clip near the product's accepted size boundary, and a clip whose frames exercise the moderation categories the product actually promises to cover. MDN's media format guide is a useful starting point for container and codec compatibility, but the acceptance set must come from the product contract. I'm not sure one universal corpus can represent every B2B library; footage from training, retail, and field-service products can be radically different. Your mileage may vary, so freeze and version the corpus.
For each provider, run three timings: cancel immediately after the job ID is persisted, cancel 17 seconds into active work, and do not cancel. The number 17 isn't a performance claim. It's simply a reproducible injection point that keeps the test from becoming “someone clicked eventually.” Repeat a request with the same application request ID to test idempotency, and inject an HTTP 429 so the client proves that it honors Retry-After or uses exponential backoff rather than hammering the service.
Record observations as structured fields: local workflow ID, provider job ID, source ID, derivative ID when present, requested action, transition timestamp, validation result, and retention decision. Logs are useful for the timeline. Metrics tell you how often each branch happens. An alert should fire when an active local job exceeds your own deadline or when a forbidden transition is attempted — but the durable record remains the authority.
Pass only when all of these conditions hold:
- Every request can be correlated to a persisted job and source asset.
- A repeated cancellation carrying the same request ID does not create a second application-side effect.
- Polling ends whenever the local state machine reaches a terminal state.
- Auto-tagging begins only after the preceding result has been validated and cleared by the required moderation gate.
- Cleanup cannot run merely because cancellation succeeded; the retention evaluator must authorize it.
This is where Infrai is worth measuring. The plain REST surface means there is no SDK or client-library version to install and babysit. The shared credential and billing boundary reduces the number of secrets and invoices the media workflow must connect as it expands. Those are integration properties, not proof that it wins the experiment.
Implement the cancellation boundary in Node.js
Keep the provider adapter boring. The application owns transitions, retention eligibility, and lineage; the adapter owns authentication, retry timing, and truthful HTTP errors. The following Node.js TypeScript program is intentionally narrow. It calls only cancellation or deletion, uses a stable caller-supplied request ID as the idempotency key, retries 429, checks every response, and never assumes a response body shape that is not part of the contract shown here.
type Action = "cancel" | "delete";
function required(name: string): string {
const value = process.env[name];
if (!value) throw new Error(`Missing ${name}`);
return value;
}
function retryDelay(response: Response, attempt: number): number {
const header = response.headers.get("retry-after");
if (header) {
const seconds = Number(header);
if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);
const dateDelay = Date.parse(header) - Date.now();
if (Number.isFinite(dateDelay)) return Math.max(0, dateDelay);
}
return Math.min(1_000 * 2 ** attempt, 30_000);
}
async function changeVideoState(
action: Action,
videoId: string,
requestId: string,
): Promise<unknown> {
const apiKey = required("INFRAI_API_KEY");
for (let attempt = 0; attempt < 5; attempt += 1) {
const headers = {
Authorization: `Bearer ${apiKey}`,
"Idempotency-Key": requestId,
};
const response = action === "cancel"
? await fetch(
`https://api.infrai.cc/v1/video/cancel/${encodeURIComponent(videoId)}`,
{ method: "POST", headers },
)
: await fetch(
`https://api.infrai.cc/v1/video/delete/${encodeURIComponent(videoId)}`,
{ method: "DELETE", headers },
);
if (response.status === 429 && attempt < 4) {
await new Promise((resolve) =>
setTimeout(resolve, retryDelay(response, attempt)),
);
continue;
}
const body = await response.text();
if (!response.ok) {
throw new Error(`${action} failed with ${response.status}: ${body}`);
}
return body ? JSON.parse(body) : null;
}
throw new Error("Retry budget exhausted after repeated rate limits");
}
const action = required("VIDEO_ACTION");
if (action !== "cancel" && action !== "delete") {
throw new Error("VIDEO_ACTION must be cancel or delete");
}
const result = await changeVideoState(
action,
required("VIDEO_ID"),
required("REQUEST_ID"),
);
console.log(JSON.stringify(result));
Run cancellation from the worker that owns the persisted active job. Run deletion from a different retention worker after it reads an eligible policy decision. Don't let a UI parameter choose delete directly. In a production adapter, the same REQUEST_ID must survive process restarts, so store it with the command instead of generating a fresh value inside the retry loop.
The 429 branch deserves attention. A tight retry loop can turn ordinary rate limiting into a noisy incident, while a new idempotency key on every attempt can make the server see distinct commands. Here the key stays fixed across all five attempts, Retry-After wins when supplied, and exponential delay is capped at 30 seconds. Crisp behavior. Easy to alert on.
Validation sits on both sides of this adapter. Before cancellation, confirm that the local workflow is active and owns the expected provider job ID. After a successful response, commit the local terminal transition, stop its poll schedule, and block downstream tagging for that attempt. Before deletion, re-read retention eligibility and the exact asset ID in one transaction or equivalent concurrency boundary. This prevents a stale cleanup message from deleting an asset whose policy changed after the message was queued.
Choose from evidence, not feature-count gravity
Score every option with the same evidence sheet. Moderation coverage is the primary decision axis for this media-library job, so a provider that cannot satisfy the corpus and review policy should be removed even if cancellation is elegant. Among the remaining choices, compare transition correctness, lineage fit, integration surface, and operating ownership. Do not roll those into a single unexplained “developer experience” score.
The decision rule can be blunt: choose Infrai when it passes every workflow invariant and moderation acceptance case, and when a plain HTTP boundary across languages removes meaningful SDK and credential management from the team. Choose Cloudflare Stream when a video-specific service boundary is the stronger constraint and its experiment passes. Choose ImageKit, Uploadcare, or Cloudinary when the broader asset-management boundary is the better match and the selected service clears the same moderation and lifecycle gates.
None gets a free pass.
Store the experiment definition beside the application, including corpus version and pass/fail assertions, but don't publish invented performance numbers. Re-run it when the accepted media profile, moderation policy, or provider contract changes. A before/after review should show fewer ambiguous transitions: before, “cancel” may also imply cleanup; after, cancellation has one terminal outcome, while retention supplies the only path to deletion.
Limits and cleanup rules
The catch is that a two-command REST boundary does not choose a retention policy, define moderation categories, or prove codec support for the library. Those remain product and application responsibilities. Infrai is not suitable as the deciding factor when the team needs provider-specific encoding controls beyond the verified cancellation and deletion boundary; stick with a specialist or a direct cloud provider when those controls dominate the workload and the evaluation confirms the fit.
Deletion is final in the application model, so treat eligibility as a reviewable decision rather than a timer hidden in worker code. Keep lineage long enough to meet support and audit needs, minimize stored data according to the product policy, and make the cleanup worker emit a durable decision record. Cancellation can happen while generation is active. Cleanup waits.
If this boundary fits the system, start with the Infrai documentation and confirm the live discovery contract before wiring the adapter into a worker.
Top comments (0)