This message was deleted.

Some background: I am working with the automation API with an inline program, currently with local backend. Currently, I deal with a locked stack in the following way: • when calling

createOrSelectStack

, if I get a stack locked err message I run

stack.cancel()

• then I get another error when calling

stack.up

saying there are pending resources for the stack • I then call

stack.exportStack()

and

stack.importStack(deployment)

• then

stack.up

finally works I am not sure this is the right way to cope with it, especially as I don't have a way to distinguish between the 2 cases as mentioned above. Also, the way I determine the error type is by textual search on the error message which is far from optimal...

I don't think you can distinguish between them currently. You just have to know what processes may be running to update the stack and see if any of them are currently running. We've had ideas to add timers or heartbeats or something to keep stacks locked to try and help with this, but nothing planned out for sure yet.

Is this the case also when working with Pulumi service backend? Or just file based backend?

I'm not 100% sure I'll have to check with the service team but I don't think those locks are release automatically either. You might be able to get the created timestamp from the lock file in the file state folder/bucket, I think the path will be something like ".pulumi/locks/<stack name>/random-uuid.json"

Thanks. If you can check with the service guys that will really help

Posted internally. All our service team is US based so probably won't get an answer till tonight though.

Great, thanks!