https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
l
Generally, async stuff is either 1) done in the provider, not the resource, or 2) is not resolved (then/apply) in the constructor, but left as a property with an Output value.
Can you expose userIds as a property, rather than a local variable?
The dependency on it in adGroup is fine, since Pulumi will handle that. Are there any other dependencies on it further down?
w
We need it when creating the adGroup, which we do want to do in the constructor (I think) since we do want a concept of a team that has a set of "children"
nope, that is the only dependency
so you're saying I can just depend directly on the promise and not resolve it?
l
Since that's the only use of it, I don't think it should be causing a problem. Does the code inside 
getUsers()
resolve anything outside of the Promise? If everything is deferred until the Pulumi engine is doing its thing, you should be okay.
w
It is quite simple:
Copy code
const getUsers = async (members: string[]) => {
    const users = await azuread.getUsers(
        {
            userPrincipalNames: members
        }
    )
    return users.objectIds;
}
l
Heh, that was exactly the example I was coming up with 🙂
That won't work, since you're awaiting before the engine gets involved.
Try doing the work inside a 
then()
instead of an async/await block.
Same thing effectively, but I think Pulumi handles it better because it's close to Output/apply?
w
got it, so it is the async/await stuff that is causing the problem. "Promise style" will work (last famous words)
l
That's my understanding, yes.
Plus you can skip the extra function 🙂
w
yes
l
pulumi.output(azuread.getUsers({ userPrincipalNames: members}).then(u => u.objectIds))
Or equivalently 
pulumi.output(azuread.getUsers({ userPrincipalNames: members})).apply(u => u.objectIds)
I would go with the 2nd one, since then the Pulumi dependency-resolution logic gets involved earlier and maybe can make better decisions?
w
ok, so I still need to put it in an output?
hm... still same issue. I know I can work my way around it by validating the input (it is an automation application), but I do want to understand why it isn't working and failing as expected.
so the correct way to do it is to move all the async calls out from the constructor I think. Then I got it behaving like I expected.
🎉 1
One question I have though is how should one go about getting values async if they depend on the output from another resource? Does that also have to be done outside of a constructor, or maybe pulumi knows how to deal with that properly since it is a resource creating the output?
l
I was under the impression that if the value is to be passed into a resource constructor, it would be fine to retrieve the value inside an apply, and pass the returned output to the constructor. But that didn't work for you yesterday, so I'm at a loss to explain this.
👍 1
w
Maybe @broad-dog-22463 can help explain? Or can point to someone. It isn't urgent by any means, but it would be nice to understand what the “right” way is.
783 Views
Open in Slack
PreviousNext
Powered by