A generic design question: why is a stack reference output an instance of

Output

? Stack reference outputs are read-only at runtime and they don't change during the execution, right? Why is it a promise then?

Pulumi functions by building a representation of your desired state by interpreting your pulumi code first. Your pulumi code is executed to completion in order to build that desired state and dependency tree before any requests are made to your cloud provider. That is why resource outputs are promises, because they are not known at the time that you pulumi code is executed. That's also why your resources are declared synchronously.

Thats a resource output not a stack reference output. A stack reference output is static at time of reading.

I understand the resource outputs in general - they can and will change at runtime (as requests are made to cloud provider APIs). Stack reference outputs will not change at runtime - Pulumi just reads the state to get to them

I didn't realize he was asking about stack references in particular. Honestly I think that's just because they were written to function like the other resources. Again, I don't think that request to get those stack outputs is made right when your pulumi code is first executed, so those values also aren't known at that time. Maybe someone else can chime in. You're correct that it won't change when it is read, but that doesn't mean it is read before your other resources are declared. That request is still deferred until after your desired state is built.

so, a leaky abstraction of the internal implementation model? 🙂

how would you represent the output of a delayed asynchronous request if not a promise?

I don't see why it has to be async in the first place?

because your state could be stored in cloud provider blob storage, or in the pulumi API - both of which would necessitate an http request?

right, and it can't be a synchronous http request?

There's nothing preventing you from just awaiting the output in your pulumi code if you want. It's built into the dotnet sdk https://github.com/pulumi/pulumi/blob/5f9f38c9c955e32eb753ed13568dfddeda4e22df/sdk/dotnet/Pulumi/Resources/StackReference.cs#L92

I'll look into awaiting the stack reference, thanks!

Stack references are not read only at run time and are not guaranteed to not change during execution. There is nothing preventing you from getting a stack reference to a stack that is currently being `up`ped.

true, I didn't think about "reference state changed under my feet at runtime"

Locking isn't supported in every backend, It was recently added to file state backends but AFAIK may still require an environment variable to enable

true, but that's the plan anyway, right? To prevent this exact situation - a stack reference output changing under the feet of another stack that's referenced it, effectively making

preview

and

up

yield different results

well currently internally preview and up are separate actions. meaning even if a lock was acquired for the first action I don't think we're holding the same lock for the next action

I saw that, yeah, looks extremely useful!