Why photo-export retries can multiply files
An archive team needs to convert a set of authorized exhibit photographs into display-size WebP previews. One worker loses connectivity after writing a preview but before recording success. A job platform may retry that task, and a naïve exporter writes a second file with a new name. The batch now contains duplicate artwork and inconsistent audit records even though its task eventually reports success. Google Cloud Run jobs offer task retries for transient failures, but they do not make a photo-export procedure idempotent automatically. Design the output identity, retry behavior, and final editorial approval as distinct responsibilities before scaling the workflow.
Understand jobs, executions, and tasks
Unlike a Cloud Run service that receives requests, a Cloud Run job runs one or more tasks to completion. An execution can include independent parallel tasks; the official documentation currently describes configurations supporting up to 10,000 tasks. Each task receives a CLOUD_RUN_TASK_INDEX and CLOUD_RUN_TASK_COUNT environment variable, allowing code to select a stable subset of the input dataset. A task can fail and restart according to the configured maximum retry count. Job success requires all tasks to complete successfully, but that status does not prove that the resulting images meet color, copyright, or identity standards. Record execution IDs and task-level output references so a green status can be audited.
Partition the input deterministically
Start with a fixed, versioned source manifest containing immutable object identifiers and approved source generations. Assign each photo to a task using a deterministic rule based on the manifest and task index. Do not use the time a worker started or a random order returned by storage listing as the basis for partitioning. If an input batch changes while an execution is running, a restarted task could process a different set of images than it saw originally. Freeze the manifest version for that execution. Different task counts require a documented repartition strategy; do not silently compare outputs produced under two different distributions as if they represented the same run.
Make the output path stable across retries
Define the output key from the source asset ID, approved revision, transformation profile, and possibly a content hash. If the same task runs again, it should recognize an existing valid output instead of creating “photo-final-2.webp.” Use storage preconditions or a controlled commit protocol where supported, and verify a partially written object rather than blindly trusting its presence. Keep temporary outputs in a staging location, then promote a verified object under a stable name. A retry must be safe after failure at any point: before upload, after upload but before acknowledgement, and after the record was marked complete. This makes failures recoverable without rewriting the historical record.
Set retries and concurrency for real constraints
Cloud Run jobs have configurable retries, task timeouts, task counts, and maximum parallelism. Google documents a default of three task retries and configurable maximums. More parallelism can speed up independent conversion tasks, but it can also overload a shared image database, exceed upstream service quotas, or exhaust a small organization’s review capacity. Set concurrency according to your slowest dependency rather than to the largest allowed task count. Retry only errors reasonably likely to be transient; invalid source permissions, unsupported file formats, and missing approvals usually need a human or data correction. Log the reason for each failed attempt, not merely a single final status.
Use checkpoints as evidence, not just speed
A task may record a checkpoint once an input is downloaded, transformed, uploaded, and independently verified. A checkpoint must include the source identifier, exact transform version, output key, and a checksum or comparable integrity fact. On restart, the task can resume only if the checkpoint and artifact correspond to the frozen execution manifest. Otherwise, it should redo the safe portion or halt for inspection. Avoid writing personal notes, confidential collection records, or credentials into checkpoint logs. The Google documentation explicitly recommends idempotent jobs because task restarts are expected operational behavior, and a durable checkpoint helps reconcile those restarts without inventing completed work.
Compare duplicate, recovered, and approved states
An illustrative three-panel diagram distinguishes an unsafe retry that creates two public-looking previews, a controlled retry that finds the same staged output, and a final review that approves one image for display. The middle state proves only that one candidate output was recovered; it is not an editorial acceptance. A museum curator may still reject the image because its crop hides an accession label or alters meaningful color. Keep source identity and revision metadata attached to all states. These are design examples, not screenshots of a Cloud Run execution or measurements from a live photo conversion dataset.
Audit failures at the task and batch levels
After execution, inspect which task indexes completed, which retried, and which exceeded their retry limits. Compare expected source IDs from the frozen manifest against staged output IDs. Flag missing files, unexpected duplicates, checksum changes, and transformations produced with a mismatched configuration version. A job can be operationally successful while the wrong source revision was selected, so source validation must be independent. If a task failed, do not re-run the entire batch blindly when output writes are not proven idempotent. Quarantine questionable artifacts and reconcile them against logs before starting a targeted authorized retry.
Release only a reviewed export set
The final release gate should receive a manifest that states every expected input, its output path, transformation settings, integrity data, and curator approval. Require a second check that no temporary or unlicensed image escaped staging. If a late retry finishes after the reviewer approved the batch, it must not replace the approved object silently. Preserve a rollback or previous export version so a bad conversion can be withdrawn without touching the original photo. Cloud Run handles the mechanics of task execution and restart. Stable naming, input freezing, rights management, and human image inspection are application and editorial controls that you must implement separately.
How We Research
Our research consulted these named official documents: Google Cloud Run: Create jobs; Google Cloud Run: Jobs retries and checkpoints best practices; Google Cloud Run: Resource model. We checked tool behavior, version-specific options, and stated limitations against an illustrative museum scenario. The examples are suggested implementation and editorial review procedures, not production tests. We did not call the services with live patron records, benchmark latency or accuracy, measure storage savings, or obtain third-party consent. All images are original explanatory drawings rather than screenshots or claimed measured results. Verify provider documentation, service availability, access policies and current organization rules before adoption; keep final publication approval with authorized staff.
Frequently Asked Questions
Cloud Run retries failed tasks according to their configuration; inspect task outcomes and the final execution status before deciding whether to rerun anything.
CLOUD_RUN_TASK_INDEX and CLOUD_RUN_TASK_COUNT are available to tasks, but your application must define stable input partitioning.
No. Your application must use deterministic output identity and safe commits so a restart cannot create duplicate side effects.
No. It confirms the configured tasks completed; separate source, integrity, rights, and visual checks remain necessary.
No. Retry transient faults within limits, but route permanent data, permission, and approval errors to review.