Pulumi state locking behavior during concurrent stack updates

Concurrency Control in Stack Operations

Pulumi implements state locking to prevent corruption when multiple processes attempt to execute pulumi up or pulumi destroy on the same stack. Under standard behavior, if a stack is already locked, any subsequent modification attempt fails immediately with an error identifying the lock holder.

Execution Constraints

In automated CI/CD pipelines, this immediate failure can disrupt deployment queues. There is currently no apparent CLI flag to enable a polling or waiting mechanism that would allow a process to queue until the lock is released by the preceding operation.

Additionally, unexpected process terminations may leave a stack in a locked state, requiring manual intervention via pulumi stack unlock.

• Is there a supported configuration to make the CLI wait for a lock rather than failing immediately?
• Does the locking behavior or timeout logic differ when using the Pulumi Service compared to self-hosted backends like S3 with DynamoDB?