Retry behavior without duplicate writes in Pulumi

Goal

Determine how Pulumi’s retry mechanism prevents duplicate writes while maintaining consistency across multiple resources.

Constraints

Pulumi’s engine assumes provider idempotency; however, not all providers fully implement it, and the engine lacks cross‑resource transaction guarantees. A transient failure can leave the stack partially applied, and a subsequent run may or may not re‑issue API calls depending on provider feedback.

Unresolved Questions

1. Does Pulumi provide any built‑in support for rolling back a partially applied stack after a retry?

2. Can providers expose explicit idempotency metadata that Pulumi can enforce during retries?

3. Is there a way to configure Pulumi to treat a failure on one resource as a failure for the entire stack, preventing a second apply from proceeding?