Pulumi and Cloud Provider APIs: How to Diagnose Deployment Failures from Logs

Question

Diagnosing Deployment Failures with Pulumi Logs
When a pulumi up fails, operators rely on Pulumi’s structured logs to determine whether the error originates from the provider or from Pulumi’s internal retry logic. The logs include provider‑specific error codes, raw payloads, and status fields, but Pulumi does not translate these into higher‑level, user‑friendly messages. Consequently, the failure context may be obscured by the lack of explicit retry configuration.
Current documentation does not specify the number of retry attempts, back‑off strategy, or whether a failure after a retry should abort the entire stack update or allow the remaining resources to proceed. This ambiguity makes it difficult to diagnose whether a failure is transient or persistent, and to plan deterministic failure handling.
What is the default retry policy for transient provider errors in Pulumi 4.x?  Should Pulumi expose configuration options for retry attempts and back‑off?  When a retry fails on the second attempt, does Pulumi abort the stack update or continue with remaining resources?

Tasadduq Burney · Answer

Answer: Default retry policy in Pulumi 4.x
The Pulumi deployment engine itself does not retry a failed resource operation. Any retries you see in the logs originate from the provider’s internal SDK or bridged Terraform provider helpers, not from Pulumi core.
Confirmed facts

When a resource create/update/delete returns an error, Pulumi records it as a failure immediately.
  If a resource fails, Pulumi aborts that resource and any resources that depend on it, but continues to schedule independent resources that are already in flight. The overall pulumi up exits with an error.
  There is no documented engine‑level retry count, back‑off strategy, or user‑exposable option to configure retries for provider CRUD calls in Pulumi 4.x.

Likely explanation of what you see in logs
Repeated attempts in the output are usually the provider’s SDK retrying on transient errors (e.g., HTTP 429/5xx, throttling). Once the provider’s internal retry budget is exhausted, the terminal error bubbles up to Pulumi, which then treats the operation as failed.
Steps to diagnose from logs

Run the update with maximum verbosity:pulumi up --verbose=9 --logflow
  Look for repeated request/response pairs that belong to the provider process (often prefixed with the provider name or SDK logging). These indicate provider‑side retries.
  Identify the final error message and its provider‑specific code (e.g., ThrottlingException, InvalidParameter). Distinguish transient codes (429, 5xx) from persistent ones (validation, permission).
  Check the provider’s documentation for any retry‑tuning options (e.g., maxRetries on the AWS provider, environment variables for Azure SDK). Adjust those if you need to change the provider’s retry behavior.

Missing diagnostic detail
To give a precise recommendation about whether you can tune retries, we need to know which cloud provider (and its version) you are seeing the failure with, because retry settings and defaults vary between AWS, Azure, GCP, and Kubernetes providers.

Pulumi and Cloud Provider APIs: How to Diagnose Deployment Failures from Logs

Diagnosing Deployment Failures with Pulumi Logs

1 answer

Answer: Default retry policy in Pulumi 4.x

Confirmed facts

Likely explanation of what you see in logs

Steps to diagnose from logs

Missing diagnostic detail

Your perspective belongs here.

0 question comments