Packer HCL2 and Cloud Provider APIs: Idempotency during Post-Processor Retries

Artifact Upload Reliability

When utilizing HCL2-based builds, Packer employs post-processors to transition build outputs—such as snapshots—into registered cloud artifacts. This integration boundary relies on the underlying provider SDKs to manage network-level failures and API retries.

Consistency Constraints

Because Packer lacks a global retry configuration block in HCL2, the responsibility for preventing duplicate writes during a retry event falls to the cloud provider's API implementation. While the manifest post-processor can record resulting artifact IDs, it does not natively govern the idempotency of the upload process itself.

There is uncertainty regarding how different provider plugins handle existing artifacts when a post-processor is re-triggered after a partial failure.

• Does the amazon-import post-processor utilize specific idempotency tokens to prevent duplicate AMI registration during SDK-level retries?
• How can a build be configured to ensure that a retry of the post-processing phase does not result in redundant cloud resources?