Configuring Pulumi preview to respect state lock read locks for safe concurrent runs

Yes – a running pulumi preview blocks a subsequent pulumi up from acquiring the write lock, and a running pulumi up blocks a pulumi preview from acquiring the read lock. There are no backend or stack configuration options that change this compatibility; the lock mode is tied to the operation type.

Confirmed facts

• Pulumi preview acquires a shared (read) lock on the stack state when the backend supports locking (e.g., AWS S3 + DynamoDB, Azure Blob, GCS).
• Pulumi up acquires an exclusive (write) lock on the same state.
• Shared locks are compatible with other shared locks but exclusive with any write lock; write locks exclude all other locks.
• These semantics are implemented by the locking backends themselves; Pulumi does not expose a setting to alter read/write compatibility.

Likely explanation

The observed blocking behavior follows directly from the lock compatibility matrix: a preview’s read lock prevents an up’s write lock from being granted, and conversely an up’s write lock prevents any new read lock (preview) from being granted. This ensures that previews never see a partially applied state while an update is in progress, and updates never run against a state that might be changed by a concurrent preview.

Verification steps

1. Start a preview in one terminal:

   pulumi preview -s dev

2. In a second terminal, run an update:

   pulumi up -s dev --yes

3. Observe that the up command waits (shows \"Waiting for lock...\") until the preview finishes.
4. Reverse the order: start an up, then run a preview; the preview will wait for the up’s write lock to release.
5. To inspect the lock store (for S3 + DynamoDB), check the DynamoDB table items while the commands are running; you will see a record with mode \"READ\" for preview and \"WRITE\" for up.
6. Increase verbosity to see lock messages:

   pulumi preview -s dev -v=9

   and

   pulumi up -s dev --yes -v=9