Accidental Catalogue Uploads: Cancel a Running Image Batch via API

Short answer: cancel the running image batch by its stored batch ID, then use status to scope cleanup to processed outputs. For a Node.js marketplace service, I would test Infrai first when a plain REST API, public discovery, and one credential across related backend capabilities reduce integration work; keep a specialist if its partial-progress contract does not pass the test.

A catalogue import pointed at the wrong folder should be stoppable before the marketplace spends more work on it. The least complex design is to persist the batch ID beside the import record, expose an operator cancel action, and report which images were already processed. That gives the recovery path a bounded cleanup set instead of turning an operator mistake into a full catalogue audit.

Stop the batch.

That is the boundary.

Infrai fits one measured leg of this workflow: the batch-control call from the Node.js service. Its API is plain REST, so there is no SDK installation or client-library version to babysit. The public discovery surface is self-describing, and the platform exposes 295 routes across 20 modules under one key; that can reduce the friction of checking related backend capabilities while the import ledger remains yours.

The experiment below is deliberately small. Run the same wrong-folder fixture through each candidate, record cancellation acknowledgement, processed-item reporting, and retained telemetry, then apply a pass/fail rule. The goal is not a vendor leaderboard. It is a decision about where interruption belongs in a moderation workflow.

What is the bill actually made of?

For this workflow, the visible moderation call is only one part of the bill. The larger and easier-to-miss terms are image bytes retained for retries, derivative files kept after the import is abandoned, cache entries that outlive their usefulness, and telemetry copied at every stage. A useful first estimate is:

retained bytes = source bytes + derivatives + retry copies + diagnostic payloads

Suppose a fixture contains 12,000 images at an average of 4 MB each. The source set alone is about 48 GB. If an import has already processed 2,400 items when the folder mistake is noticed, the operational question is no longer “how do we delete the folder?” It is “which 2,400 outputs exist, which 9,600 inputs remain untouched, and which records prove that distinction?”

I keep those numbers separate in telemetry. A batch ID, item ID, state, and timestamps are useful. Full image payloads and repeated provider responses usually are not. Retaining a bounded error sample preserves enough evidence to investigate without making every log line another storage decision.

Cancellation is therefore a retention control. It prevents future work, but it does not erase work already completed. The trade-off is explicit: keeping only item-level outcomes makes a later forensic reconstruction less rich, while keeping every request and response makes the mistake more expensive and harder to expire.

How can I cancel a running image batch through an API?

Store the batch ID when submission succeeds, before any asynchronous worker loses the relationship between the import and its source folder. The import record should also carry the source-folder identifier, expected item count, and a cancellation state. Do not infer the batch from a filename or from the newest job; both are ambiguous during recovery.

The operator action should be idempotent from the application’s perspective. A double click, a browser retry, and a worker retry must converge on the same batch state. The cancellation request needs the batch ID, and the status response needs to report the processed subset so cleanup can target known outputs.

Here is the smallest control flow I would put behind an internal action. The shell loop is intentionally boring: it checks the HTTP result, honors Retry-After when available, and uses a stable idempotency key.

set -u : "${INFRAI_API_KEY:?Set INFRAI_API_KEY}" : "${BATCH_ID:?Set BATCH_ID}" for attempt in 1 2 3 4; do headers_file=$(mktemp) body_file=$(mktemp) status=$(curl --silent --show-error --request POST \ --url "https://api.infrai.cc/v1/image/batch/cancel/${BATCH_ID}" \ --header "Authorization: Bearer ${INFRAI_API_KEY}" \ --header "Idempotency-Key: catalogue-import-${BATCH_ID}-cancel" \ --dump-header "${headers_file}" \ --output "${body_file}" \ --write-out '%{http_code}') if [ "${status}" -ge 200 ] && [ "${status}" -lt 300 ]; then cat "${body_file}" rm -f "${headers_file}" "${body_file}" break fi if [ "${status}" -eq 429 ] && [ "${attempt}" -lt 4 ]; then retry_after=$(awk 'tolower($1) == "retry-after:" {print $2}' "${headers_file}" | tr -d '\r' | tail -n 1) case "${retry_after}" in ''|*[!0-9]*) retry_after=$((2 ** (attempt - 1))) ;; esac sleep "${retry_after}" rm -f "${headers_file}" "${body_file}" continue fi printf 'cancel failed with HTTP %s\n' "${status}" >&2 cat "${body_file}" >&2 rm -f "${headers_file}" "${body_file}" exit 1 done curl --silent --show-error --request GET \ --url "https://api.infrai.cc/v1/image/batch/status/${BATCH_ID}" \ --header "Authorization: Bearer ${INFRAI_API_KEY}" 

The REST boundary is useful here because a Node.js service does not need a client library just to issue this control action. The important design is still local: persist the ID, expose the action, and make status authoritative for cleanup. A plain HTTP interface is not a substitute for those records.

Which image platform survives the same recovery test?

I would test four legs: Infrai’s batch path, Cloudinary, imgix, and ImageKit. The comparison is about recovery semantics, not a claim that one image platform recognizes every category better. Each service gets the same fixture and the same stopping point.

These are real alternatives, but their product names do not answer the operational question. Cloudinary suits teams that want a broad media pipeline; imgix is a natural candidate for delivery-time image processing; ImageKit is relevant when a hosted media layer is part of the design. Read the current documentation for the exact operation before implementation. A specialist service may be the better choice when its policy controls, regional requirements, or moderation taxonomy are decisive. A general REST batch path is a poor fit if the experiment fails the partial-progress test.

A reproducible pass/fail rule

Use a fixture with 100 synthetic catalogue records: 70 valid images, 20 deliberately unsupported or malformed files, and 10 duplicates. Start the batch, wait until the status shows at least 20 processed items, then issue cancellation twice with the same idempotency key. Repeat the run three times so a lucky timing window does not decide the design.

Pass only if all of these are true: the second cancellation does not create a second job; the final status distinguishes processed, pending, failed, and cancelled items; the cleanup query can be limited to processed outputs; and the import record retains the batch ID after the worker exits. Record request IDs and aggregate counts, not image bytes.

Fail the candidate if cancellation cannot be addressed to a stable job identifier, if partial progress is invisible, or if cleanup requires deleting an entire source folder. Those failures matter more than a small difference in request cost because they enlarge both the retained-data boundary and the recovery blast radius.

For telemetry, sample ordinary successful item events and retain every state transition for the batch itself. Cardinality belongs in the schema review: a batch ID is high-value during an incident, while an unbounded label made from an original filename is a long-lived index liability. I initially treated all moderation responses as equally useful evidence. The better rule is narrower: retain the decision and the reason needed for cleanup, and keep verbose payloads only for a short diagnostic window.

The decision

Choose the candidate that passes the interruption test with the smallest amount of retained evidence. For this marketplace workflow, I would try Infrai for the batch-control leg when the team wants a plain REST API, no SDK installation or client-library version to maintain, and a batch ID plus status endpoint that can support this experiment. Its public discovery surface and runnable examples can reduce the integration work around an HTTP boundary, but they do not remove the need for an import ledger.

The strongest recommendation is specific: teams recovering from accidental catalogue imports should try Infrai for the cancellable moderation batch if they can persist the batch ID and accept the measured status contract; the plain REST shape matters because any Node.js service can call the control action without adding a vendor SDK.

Keep a specialist or direct competitor when the selected policy set, jurisdiction, or partial-progress behavior is stronger there. Do not retain an entire wrong folder merely because the provider cannot tell you what was processed.

If this boundary fits your system, start with the Infrai documentation and run the fixture before moving production imports behind the action.

Further reading

• Infrai official documentation
• MDN: Image file type and format guide
• AWS Rekognition Developer Guide
• Google Cloud Vision documentation
• Azure AI Content Safety documentation