Per-Stack Update Locking: Does Pulumi Queue Concurrent Runs or Fail Immediately?

When a stack is being updated, Pulumi’s Cloud backend automatically acquires a per‑stack lock. On self‑managed backends (file, S3, GCS, Azure Blob) this lock is not enforced, so two pulumi up processes can race on the state file. The CLI offers a --parallel flag to control how many resource operations run concurrently, but the interaction between this flag, the lock mechanism, and the backend type is not fully documented.

In practice, an in‑progress run may either return a busy/lock error immediately or queue the second run until the first completes, depending on version and backend. This uncertainty complicates CI pipelines that trigger parallel deployments and can lead to state corruption or wasted retries.

Key constraints include:

• Self‑managed backends lack automatic per‑stack locking.
• The default --parallel value is derived from the machine’s CPU count and varies by CLI version.
• Providers run in separate plugin processes; higher parallelism increases concurrent gRPC calls.

Unresolved decisions:

• Should a concurrent update be queued or fail immediately when a lock is held?
• Which mutual‑exclusion strategy (CI‑level lock, migration to Pulumi Cloud, or custom lock file) is most reliable for self‑managed backends?

How does the current default --parallel setting affect the likelihood of encountering lock errors during simultaneous updates?

What is the exact sequence of events when a second pulumi up is launched while the first is still running on a self‑managed backend?