This message was deleted.

IIRC, I believe this was caused by a mangled workspace.json file in

~/.pulumi/workspaces

due to parallel stack select calls

yup, deleting the folder fixes it

The issue is specifically with

selectStack

because it runs

pulumi stack select

, which sets the selected stack as current. Multiple processes simultaneously setting the stack as current can lead to corrupted global state which results in this mangled workspace file.

how would one prevent this when doing something like pulumi over http where you have no control over the calls being made?

It’s a bug/design flaw. We worked through a set of changes for 3.0 that fixed a lot of the other stack operations to not require stack selection and instead use the

--stack

flag to avoid changing the

current

stack - but we overlooked the

selectStack

function itself, which is now the one operation that changes global state and therefore cannot be parallelized.

I see, is it on the roadmap for a patch release soon? (well as it is not bc, i guess for v4?)

how would one prevent this when doing something like pulumi over http where you have no control over the calls being made?

The containing application should have some mechanism to serialize calls to

select

is it on the roadmap for a patch release soon?

It is not currently on the roadmap. Depending on what you’re trying to do, it is possible to work around by either serializing the calls to

select

or by running the operation on the workspace itself with the stack specified e.g.

LocalWorkspace.stackOutputs([stackName])

I’m trying to (consistently) have an endpoint that creates a stack and run a pulumi program. There is concurrency which is why we run this via a queue with separate processes. So everything is nicely separated by design, but since this file is in the home dir, it is shared across all pulumi runs within the same computer/docker container. Is there a way to set a path for this via some env var? Then I can put it into a dedicated tmp folder per stack.