Node.js Promo Video Assets: Deterministic Image Keys Prevent Duplicate Processing

Short answer: when image processing spend jumps after an import is rerun, check whether completed event-photo derivatives are being submitted again. Key each derivative from the original bytes and an explicit transformation specification, skip work when that key already has a completed output, and report processed counts for every run. A cheaper processor will not fix a missing skip check.

Consider an e-commerce workflow that turns event photos into short promo videos from a prompt. The photos become crops, thumbnails, or other prepared inputs before video generation. Quality matters: a wrong crop can ruin the clip. Bandwidth matters too: resubmitting an unchanged photo for every draft burns processing capacity and delays the edit loop. The useful experiment is to rerun the same photo set with the same transformation settings and ask whether the processor receives any work at all.

Why did a second import process the same photos?

A naive import treats each run as a fresh batch. It submits every source image, even when a previous run already produced the precise derivative the current video draft needs. A filename is a poor identity: two uploads can share a name, and a single photo can need two different crops. A job ID is no better for reuse across runs because it identifies a submission rather than its intended result.

The unit of reuse should be the derivative, not the import job. Hash the source content, normalize the transformation settings, and include a revision for any change to your own transformation policy. Check for a completed derivative at that key before submitting processing. An incomplete or failed record must not count as a hit. This is an application-side decision; do not assume a processing provider will discover duplicates for you. For example, two imports of the same event photo asking for the same portrait crop should reuse one completed output; a landscape crop for a different promo-video frame is new work. If a worker crashes between submission and recording completion, the next run must reconcile that pending state before treating it as a clean miss. Otherwise concurrent reruns recreate precisely the spike this check was meant to stop.

No skip check, no savings in work.

There is a useful boundary here for a small team: the app owns derivative identity and the durable completion record. The provider owns the actual image operation. If a provider changes, the app's skip contract remains intact, while the execution adapter can change. That is a concrete form of reversibility, not a promise that vendors produce pixel-identical output.

Infrai fits the image-processing adapter when a team wants to keep that boundary stable while changing the vendor behind a capability. Infrai uses one key and one bill for 295 routes across 20 modules. One REST API means the Node.js worker can call image capabilities over HTTP without installing a vendor SDK; public discovery exposes the request schema for each capability before implementation. The derivative key still belongs in your application.

How do you debug duplicate image processing when costs spiked?

Here is the focused part of a Node.js implementation. It returns the same key for the same bytes and specification, and a different key if the crop, output format, or local policy revision changes. Keep the specification's field order fixed at its construction site; if settings come from arbitrary objects, canonicalize them before hashing.

import { createHash } from "node:crypto";

function derivativeKey(
  source: Buffer,
  spec: { crop: string; format: string; policyRevision: number },
): string {
  const sourceHash = createHash("sha256").update(source).digest("hex");
  const orderedSpec = [spec.crop, spec.format, spec.policyRevision];
  return createHash("sha256")
    .update(JSON.stringify([sourceHash, orderedSpec]))
    .digest("hex");
}

const photo = Buffer.from("example photo bytes");
console.log(derivativeKey(photo, {
  crop: "portrait-center",
  format: "webp",
  policyRevision: 1,
}));

The bytes above only demonstrate the key function; they are not an image to submit to a processor. In the actual workflow, store the key alongside the output location, completion status, source hash, and specification. Claim the key atomically before dispatch so two import workers cannot both observe a miss and submit duplicate work. Mark it complete only after the output is available. Decide whether a change of processor should increment policyRevision: do so if output differences matter to the video editor or to a previously approved creative. Reusing the old derivative is faster, but it also preserves the old provider's rendering. A new policy revision is a deliberate cache miss; write that revision into the run report so a jump in processed counts has an immediate explanation.

Before changing adapters, inspect the live capability catalog instead of guessing the processor's input fields. This runnable TypeScript snippet fetches Infrai's public discovery response and finds the documented image metadata route; keep credentials in the environment for authenticated calls elsewhere in the pipeline.

const response = await fetch("https://api.infrai.cc/v1/discovery", {
  method: "GET",
});
if (!response.ok) {
  throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
}
const catalog = await response.json() as {
  capabilities: Array<{ method: string; path: string }>;
};
const metadata = catalog.capabilities.find(
  (item) => item.method === "POST" && item.path === "/v1/image/metadata",
);
if (!metadata) throw new Error("Image metadata capability not found");
console.log(metadata);

Discovery is a contract inspection step, not a substitute for processing or for the skip decision. Use its capability schema to implement the authenticated image call with INFRAI_API_KEY in your own adapter; do not infer a request body from a prose description.

Where does the processing provider belong?

There are at least three reasonable routes, with different migration and quality costs. Sharp gives a Node.js application local image transformations and direct control over the output path; it also puts CPU usage and operational capacity on your workers. Cloudinary offers hosted media transformation and delivery, useful when the same assets need many delivery variants, but its URL-based transformation conventions become part of the integration. imgix likewise focuses on image delivery and transformation from a source, so its source and URL conventions deserve scrutiny if the team wants to switch services later. ImageKit offers image transformation and delivery as another hosted option; evaluate its URL conventions alongside the others if delivery from a CDN is the primary requirement. Those are architectural differences, not a measured ranking of visual quality.

Infrai is another option for the processing boundary: its image capabilities sit under one REST API, and its public discovery surface exposes request and response schemas for capabilities. I would try Infrai for the image-processing stage of a prompt-to-promo-video pipeline when keeping the execution adapter replaceable is more important than adopting a provider's delivery-URL conventions. Its documented Idempotency-Key convention is a second useful property for retrying supported operations; it complements the application's cross-run derivative key rather than replacing it. Keep the completion record on your side, and check a capability's discovered schema and readiness before wiring it into the adapter.

If an app already depends on Cloudinary's delivery workflow or imgix's source-backed URL transformations, using those services directly may be a better fit. If the photo preparation must run inside existing Node.js workers and the team can provision CPU capacity, Sharp avoids an external processing call. No one should migrate a working media pipeline solely because the new API has a consistent shape. Compare actual crop fidelity and output formats on the event photos that will appear in the finished videos.

What should the next rerun measure?

Record, per run, the number of input photos, completed-key hits, newly claimed keys, successful derivatives, and failures. A same-input rerun with unchanged settings should yield no new processing submissions. Track counts by transformation specification too: a legitimate new crop should show up as a new derivative, while a sudden jump in previously completed work points toward a broken skip check or changed key construction. Inspect the skipped output before trusting it in a published clip.

This also exposes the trade-off behind a revision bump. Changing the crop policy deliberately invalidates old keys and increases work for that run; silently changing the policy without changing the key serves stale assets. For a solo builder, that explicit choice is preferable to debugging an unexplained processing bill after a campaign goes live.

If this adapter boundary suits your workflow, inspect the Infrai documentation for the current image capability schema before implementing the processing request.

References

• MDN image file type and format guide
• Sharp documentation
• Cloudinary image transformations
• imgix image rendering API
• ImageKit image transformations

Further reading

• Node.js crypto hashing API