This message was deleted.

Also tried with

requireOutputValue() as pulumi.Input<string>

. No change.

I haven't had a chance to test this out yet, but from what I understand looking at this code, your try catch block won't fail because it is returning a object that promises to have that stackReference eventually. (deferred execution) The same with the someId. So that try catch block won't fail. And then, you've scoped stack and someId within the try/catch block which means it isn't availabe outside of that block? If you use

const var1 = stackRef.getOutput("someConfigValue") || "default";

you can detect that you didn't get a stack value or adapt in the case it wasn't available with a default value.

The docs for requireObject and requireObjectValue imply that an error should be thrown if the stack doesn't have the object:

Fetches the value of the named stack output, or throws an error if the output was not found.

Fetches the value promptly of the named stack output. Throws an error if the stack output is not found.

The stack doesn't have the object I'm requesting (there is no

export

for it, it will never be there), so I believe the exception should be thrown. If it's not, then there's a bug in the docs. (The scope is not an issue, this is just example code.)

That is what I was trying to convey. Most things in pulumi are async and since you are not using an await on the call (I don't know if it works in pulumi), you've actually left your try/catch block context and you've moved onto the next statement.

Yes. I think that's the bug. It may be intended to work that way, but the docs imply something else: a synchronous exception. And there should be no reason not to have a synchronous exception in my use case: if the stack reference doesn't contain the output, then no amount of waiting it is going to change that, so don't wait, just throw.

I think we need to understand if the acquisition of the StackReference is synchronous and may throw exceptions or the registration of the intention to get the StackReference and all of its config options is synchronous. If we look here at the StackReference code in github, we can see that all of the properties on StackReference are

Output<>

, which will not necessarily be fulfilled at the time of creation since Output instantiations are usually deferred. I 100% agree that when you ask the StackReference for an

getRequired("name");

, if it doesn't exist, throw an exception but that is isn't the same as creating the initial StackReference object that you are using to get deferred objects.

Me too. I think we need synchronous ways to find out if the other stack exists and if it contains an output. I totally accept that getting that reference must be asynchronous. My particular use case is VPC peering: I want to know whether do not to start my peering attempt, but my app crashes when I try to get the VPC ID from the other stack, because that stack hasn't been upped yet. And the same problem happens when I want to accept the connection: the 2nd stack needs to get the connection ID from the 1st stack, but the app will crash if the connection hasn't been requested. All of this should be doable synchronously and "catchably". Currently I'm side-stepping the problem by coping my stack outputs to config. When I call config.require('PeerVpcId') and the PeerVpcId hasn't been set, I get a synchronous exception thrown. Nice and "catchable". But not as idiomatic as calling stackRef.require... (imo).

All of this should be doable synchronously and "catchably".

I think this is the hard part. Provisioning cloud resources can't be done synchronously, unless you are willing to wait, even in the event that the provisioning failed. And a Stack is a cloud resource when it is being shared via StackReference.

But you can't deploy to one stack while waiting for another stack to deploy, can you? StackReferences are different in that when you create a reference, you know that the stack behind has already finished deploying.

Pulumi has the

dependsOn

property that you can use to wait until the resource is provisioned, but in your case, your first stack/pulumi app may not have even run, so your still going to have a undefined string, and the app requesting the StackReference has to wait until another process has run.

And this applies even to

requireOutputValue

, which has this doc?

Fetches the value promptly of the named stack output. Throws an error if the stack output is not found.

I don't use stacks as a part of a workflow like that. I do have stacks that dependOn each other, but if the second stack blows up, that is ok because I have to run a CI/CD or manually build the core platform.

We use projects in a monorepo for that. In my case, I have admin, dev and prod stacks, and I need peering between admin and the other two. Which means that some resources in admin depend on resources in all three stacks.

I theory, I could have crafted that as a single massive pulumi app with all the configuration values required for all of the apps, but I prefer smaller apps and smaller configuration-per-stack to minimize how much configuration is managed.

👍 That's how I've done it too.

In a single app, you can manage dependencies with the

dependsOn

attribute.

Can I dependsOn a stackRef value?

I don't know. Generally, pulumi is very good about detecting

Output<T>

and automatically building in the dependency for you, but that still doesn't solve the problem that the dependency value doesn't currently exist.

Hmm.. sounds nice, but I don't know how to do that. We run the stacks separately. Is it even possible to run

pulumi stack select

during a

pulumi up

? Is it possible to depend on two things in two stacks at the same time? 🤔

Two console windows, yes

Yeah nah, not for me thanks. That's not pipeline-able, the potential for race conditions is extreme, and there's no way it would get past a peer review.

And I should clarify, I haven't tried running

pulumi up

on the same app on multiple stacks concurrently. Pulumi cli MIGHT stop that from happening. But in theory, you could run two stacks of the same app at the same time and they would not conflict.

But if one of those stacks has a dependsOn on a resource in the other stack, then there will be long waits. If they both have dependsOn the other stack, then there will be race conditions. I feel like the best thing here for Pulumi would be to prohibit dependsOn between stacks, and to fall back to the synchronous exceptions.

I think if you have important dependencies like you've described, I would try to do that in one app with the

dependsOn

functionality.

Needs to be one stack, too, I think.

It was great to talk about all of this! I hope it was therapeutic if not helpful. 😄

🙂 It would just help a lot to have a SynchronouslyFetchedResource or somesuch, for when we know the resource / StackReference exists before the app is run...

I don't think that is an unreasonable ask for a synchronously execute inspection. Add it as a feature request. I'll add the caveat that there may already be a way to do it that I don't know about. 😛

Closely related to this.. https://github.com/pulumi/pulumi/issues/5035